►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Measuring Developer Happiness: Analytics for Backstage - Eric Peterson, Spotify
So you're deploying Backstage at your organisation. You're making a bet that Backstage will move the needle on your engineering productivity objectives and you're investing time and resources to see it through. How do you know that bet's paying off?
Join Eric as he demystifies the process of gathering insights from your Backstage instance by offering an in-depth introduction to the Backstage Analytics API. Backstage adopters will learn how to start collecting usage data, and what key metrics to be focused on. Plugin developers will walk away with practical advice and context on how to surface more useful data to adopters.
A
Anyway,
thanks
for
coming,
my
name
is
Eric
Peterson.
You
might
know
me
as
imeap
on
GitHub
and
all
places
around
the
web.
Metrics
have
kind
of
come
up
as
side
topics
and
a
lot
of
conversations
that
we've
had
so
far
on
stage
today
and
I
kind
of
wanted
to
Center.
It
focus
it
a
little
bit
and
dive
a
little
bit
deeper.
A
So
why
should
you
trust
me
I'm,
just
a
software
engineer,
but
before
I
worked
at
Spotify,
I
worked
at
a
company
called
Tableau.
It's
like
a
data
visualization
analytics
company
for
about
eight
years,
I,
wouldn't
you
you
could
go
and
call
me
a
city,
slicking
data
scientist
or
anything
like
that,
but
I'm
at
least
data
literate
right
I
worked
at
a
company
for
me.
Naturally,
I've
been
involved
at
Backstage
for
about
two
years
at
Spotify.
A
A
A
What
we're
going
to
be
talking
about
one
of
the
things
that
I
learned
working
at
Tableau
is
that
good
analysis,
good
analytics,
is
sort
of
indistinguishable
from
storytelling
and
so
I
want
to
Anchor
The
Talk
today
on
a
little
bit
of
a
story
that
might
feel
familiar
too
A
lot
of
those
software
Engineers
out
there,
then
we're
going
to
sort
of
dissect
that
story
through
a
data
lens
and
and
see
if
there's
anything
to
be
learned
and
then
finally
we're
going
to
get
practical.
What
does
that
actually
mean?
What
can
we
do?
A
A
A
So
he
goes
in
looks
at
his
logs
the
build
logs
and
he
says:
oh
well,
it's
a
test,
that's
kind
of
failing,
but
it's
in
code
that,
like
you,
didn't
really
touch,
it
seems
kind
of
flaky,
so
he
just
re-triggers
the
build
he's
still
got
feedback
going
on
the
pr,
so
he
keeps
making
commits
pushing
him
up.
He's
he's
not
too
worried
about
it.
A
A
Now
a
little
bit
later
in
the
day.
Maybe
it's
after
lunch,
all
of
the
feedback
from
his
peers
comes
in
green,
give
it
a
thumbs
up.
Maybe
he's
commented
out
that
flaky
test
it
keeps
kind
of
failing
and
passing
and
failing
and
passing
you
know
a
little
shortcut,
so
you
can
ship
it
to
production
it's
time
to
ship
it.
So
you
ship
it,
you
merge
it
Master
build,
starts
and
you're
good
to
go.
A
Now
it's
been
a
long
day,
and
maybe
you
go
out
into
the
forest
and
in
the
woods
in
Sweden,
and
you
get
a
page
in
your
pocket
you're
on
call
but
you're
good.
You
have
your
laptop
with
you.
You
got
your
mobile
Broadband,
so
you
open
up
the
laptop,
probably
looks
at
that
email
that
page
acknowledges
what's
happening,
starts
diving
into
graphs
and
logs,
and
that
starts
looking
through
the
error
rate
thresholds
kind
of
high
okay.
Let's
look
at
the
logs,
oh
there's
kind
of
like
an
error.
A
A
Whoops,
well,
you
know
it's
it's
late
in
the
day,
you're,
probably
not
going
to
be
able
to
get
to
the
bottom
of
the
actual
error,
so
why
not
just
go
and
pin
that
deploy
that
it
happened
just
prior
to
what
you
had
deployed
and
call
it
a
day,
you'll
get
to
the
bottom
of
it.
The
next
day
for
now
you're
in
the
woods
you're
enjoying
it
it's
time
to
party
right
feels
familiar
right.
This
is
this
is
a
thing
that
people
go
through
on
a
fairly
regular
basis.
A
A
You
might
have
a
service
that
has
all
of
the
alerts
that
have
been
triggered
and
sent
to
the
responsible
engineer
on
call.
When
did
the
status
change?
How
long
did
it
take
to
go
from
acknowledged
to
cleared
that
kind
of
you
might
have
every
single
deployment
that's
gone
out
in
your
kubernetes
cluster?
How
long
did
it
take?
What
was
the
status
of
the
deployment
Etc
et
cetera
Etc?
A
Can
be
good
right
if
you're
focused
on
a
particular
problem
in
one
of
those
areas?
Maybe
you
want
to
measure
like
deployment
velocity.
It
can
be
really
really
useful
to
have
that
information,
but
it's
also
quite
a
bit
of
effort
to
actually
make
it
happen.
You
got
to
go
out
to
every
one
of
those
SAS
providers
connect
with
their
apis
Warehouse
that
data
transform
it
visualize
it
like
it's
it's
it's
not
an
easy
lift.
A
I
guess
one
could
say
and
what's
worse
is
that
when
you
have
that
kind
of
really
low
level
metadata
like
every
single
commit,
it's
really
easy
to
start,
focusing
on
like
okay.
Well,
my
top
developers
do
like
10
commits
a
day
or
something
like
that,
and
it's
easy
to
get
into
situations
where
you're
setting
up
like
commit
quotas
and
you're
managing
to
that
you're
incentivizing.
Well,
we
need,
like
10,
commits
a
day
from
every
developer,
and
that's
that's
the
kpi
that
we
care
about.
A
Kind
of
the
worst
thing
about
it,
I
think
in
my
opinion,
is
that
you
just
end
up
with
all
of
these
silos
of
data
that
are
actually
really
difficult
to
connect
to
one
another.
You
don't
really
have
a
sense
like
there's
no
way
to
retell
that
story
that
we
just
walked
through.
You
can
look
at
The
Silo
itself,
but
it's
hard
to
look
across
those
things
now.
A
I,
don't
know
if
you
remember,
but
we're
at
this
thing
called
backstage
con
and
there's
a
tool
called
backstage
and
there's
some
really
interesting
advantages
having
such
a
tool,
if
you
think
about
deploys
that
are
happening,
builds
that
are
happening
when
Bowie
is
like
starting
his
day,
diving
into
a
PR
or
deploying
something.
Where
is
he
doing
that
he's
probably
doing
it
in
backstage
when
Bowie
got
that
alert
got
it
got
his
page
and
he
started
to
dive
in
looking
at
logs
and
stuff
we're
going
to
do
that.
A
A
That's
all
well
and
good,
but
we're
not
quite
there.
Yet
what
we
need
to
do
is
sort
of
translate
each
of
those
key
events
that
Bowie
went
through
into
Data
that
we
can
then
analyze
later
and
so
what
I'm
going
to
do
now
being
the
sort
of
lingua
file
that
I
am,
is
to
help
you
learn
the
grammar
of
how
to
tell
a
story
in
backstage
through
apis
and
Json,
and
things
like
that
buckle
up
at
a
high
level.
A
There's
this
thing
called
the
analytics
API
in
backstage
it's
event
based
like
a
lot
of
analytics
tools
and
it
sort
of
splits
the
responsibilities
among
two
constituencies:
I
guess,
if
you
raise
your
hand-
and
you
were
a
plug-in
developer
you're
there
at
the
Top,
If
You
raise
your
hand
and
said
you're
like
an
app
integrator
you're
responsible
for
backstage
deployment,
you're
sort
of
toward
the
bottom.
There
plug-ins
themselves
are
the
ones
that
are
responsible
for
firing.
A
Those
events
like
a
deploy
or
emerge,
or
what
have
you
they
use
a
core
API
to
do
so,
which
is
provided
by
backstage
core.
It's
been
available
for
over
a
year
now,
I
think.
So
it's
there
for
you
to
use
today
app
integrators
are
responsible
for
providing
sort
of
a
concrete
implementation
of
that
API,
which
is
itself
responsible
for
translating
the
event
into
something
meaningful
for
an
external
analytics
platform
like
a
Google
analytics
or
a
segment
or
an
amplitude,
or
something
like
that.
A
A
A
A
Fire
that
hook
in
your
component,
you
get
that
object
and
in
some
kind
of
event
handler
like
a
click
Handler,
you
would
call
the
capture
event
method
on
that
returned
object
and
on
that
event,
capture
method.
You
just
provide
that
action
like
Navigator,
deploy
and
the
subject
the
thing
that
it
was
related
to
now
in
order
to
help
y'all
who
are
responsible
for
backstage
instances.
There
are
some
core
events
that
are
provided
out
of
the
box
for
you,
you
don't
have
to
instrument
these
things.
A
Navigating
around
backstage
is
captured
as
this
navigate
action
and
it's
sort
of
akin
to
a
page
view
event
in
a
traditional
web
Analytics
tool
and
also
clicks
on
links
and
buttons
that
use
that
come
from
core
components.
Library
are
also
automatically
captured
with
a
click
action
and
then
the
subject
is
typically
the
text
that
was
clicked
on.
A
A
If
we
want
to
tell
a
story,
we
can't
just
use
Simple,
verbs
and
subjects
right.
We
need
to
be
able
to
describe
these
things
in
a
little
bit
more
detail
at
Spotify.
We've
had
event
tracking
in
our
backstage
instance,
for
quite
a
while,
and
one
of
the
patterns
that
we've
seen
before
we
had
this
analytics.
Api
open
sourced
is
sort
of
stuffing
additional
details
into
one
of
those
two
things
the
event
or
the
subject.
A
A
You
can
describe
kind
of
like
an
adverb
where
how
the
event
relates
to
things
sort
of
in
the
context
around
it,
and
so
you
can
use
this
analytics
context,
sort
of
context
provider
somewhere
in
your
reactory
above
where
the
event
was
fired,
to
provide
details
like
was
the
engineer
on
call
at
the
time
that
the
event
happened,
for
example,
and
just
providing
that
context
around
the
event.
You
end
up
with
a
Json
blob.
That
kind
of
looks
like
something
to
the
right.
A
A
We
provide
a
plug-in
ID
for
the
plugin
that
provided
the
component
where
the
event
was
fired.
We
provide
an
extension
name
where
sort
of
where,
in
the
UI
that
the
fire
event
was
fired,
for
example,
deploy
button
and
also
on
navigation.
We
provide
a
route
ref
so
that
you
don't
need
to
know
the
exact
URL
of
the
place
that
the
event
took
place.
You
can
get
the
route
ref
identifier
and
all
of
this
is
provided
for
you
out
of
the
box.
A
A
Now,
for
those
of
you
on,
if
you're,
not
necessarily
a
plug-in
developer,
you're
just
interested
in
actually
having
access
to
this
data
at
all,
you
need
to
care
about.
Is
the
analytics,
API
interface
itself?
It
just
has
that
one
method
capture
event
and
you
just
need
to
provide
a
definition
for
this
method
by
default,
it
just
kind
of
gets
black
hole.
A
In
reality,
it's
actually
probably
even
easier
than
that.
There
are
analytics
modules
that
are
open
source
that
you
can
install
and
provide
out
of
the
box
today.
I
believe
Google
analytics
is
the
one
open
source,
one
that
comes
to
mind.
I've
also
seen
a
PR
for
a
segment
analytics
provider,
that's
still
sort
of
in
progress,
but
this
is
an
area
where
you
can
absolutely
get
involved
and
plug
in
any
kind
of
analytics
provider
that
you
use
vrs
and
issues
and
things
welcome
or
we
can
hack
on
it
at
coupon.
A
A
There
are
a
lot
of
really
important
actions
that
users
take
in
backstage
today
that
are
also
as
yet
uninstrumented.
So
my
goal
here
is
that
now
that
you
are
aware
of
this
API
and
now
that
you
see
the
opportunity
ahead
of
us
being
able
to
retell
that
story
in
data
that
will
have
much
better
event
instrumentation
in
backstage
going
forward.
A
A
B
So
I
really
liked
the
look
of
the
react
analytics
stuff
that
was
up
there.
Is
there
something
with
a
similar
syntax
that
you
might
see
that
we
might
see
soon
from
Backstage
on
the
back
end,
some
sort
of
analytics
that
that
is
similarly
presented
and
similarly
accomplished
from
the
from
from
the
back
backend
side
of
things
great.
A
C
D
Eric
great
talk
so
I
think
a
lot
of
this
talk
focused
on
the
metric
Collection
part
right
and
instrumenting
the
front
end
to
collect
it
and
I
think
you
alluded
to
this
in
in
the
penultimate
slide
that
how
do
you
kind
of
like
great
we've,
collected
these
metrics
like
what's
next?
What
are?
Can
you
give
us
an
inkling
of
like
how
should
we
think
about
you
know?
We
have
this
sort
of
different
bits
of
data
that
happen
in
in
the
sdlc
and
an
incidence
life
cycle,
and
we
can.
D
A
That
kind
of
stuff
I
think
where
the
real
magic
is
going
to
be
in
the
future,
is
sort
of
being
able
to
combine
some
of
those
key
points
of
developer
experience
with
sort
of
the
opposite
end
of
the
spectrum
of
how
we
measure
developer
Effectiveness,
which
is
sort
of
more
along
the
lines
of
the
space
framework.
Where
you're
looking
at
satisfaction
you're.
Looking
at
how
people
are
feeling
about
particular
tools,
I
think,
there's
a
magical
place
where
we
can
look
at
the
data.
A
So
a
couple
of
advantages
out
of
the
box
is
sort
of
like
you
can
absolutely
hook
up
the
ga
SDK
to
this
framework
and
be
able
to
collect
events
in
Spotify.
We
directly
spoke
to
GA
in
the
past
and
so
we're
sort
of
tied
to
it
in
a
way.
That's
what's
very
difficult
to
overcome.
I
guess:
there's
lots
of
code
with
lots
of
events
being
fired
and
we're
trapped
on
GA.
A
Essentially,
so
the
the
agnosticism
of
the
API
actually
makes
it
so
that
you
can
very
easily
shift
to
a
different
provider
without
having
to
do
a
whole
lot
of
work.
Hardly
any
work
at
all!
Really,
that's
probably
the
the
first
one.
The
second
one
is
just
like
if
you're
working
on
inner
Source,
plugins
or
something
like
that
leveraging.
This
API
ensures
that
if
you
wanted
to
contribute
that
back
to
the
open
source,
you'd
be
able
to
do
so
very
quickly
without
having
to
re-instrument
things
in
your
plugin
thanks.