►
From YouTube: Manage:Analytics Weekly Meeting 2020-05-05
Description
The Analytics group talks about blockers, "on deck" issues, and cool stuff from the past week.
A
A
A
C
Okey
doke
yeah
I've
got
a
couple
things
I
made
a
little.
Video
of
this
I've
been
talking
about
object
model
for
a
while,
so
I
made
a
little
video
right
here,
give
me
a
ten
minute
overview
of
of
like
using
objects
and
how
you
can
use
objects
to
inform
UX
strategy
and
then
use
it
basically
to
determine
where
you
can
invest
your
efforts.
C
So
this
is
like
the
first
step
of
helping
designers
across
gitlab
think
a
little
bit
more
strategically
about
how
they're
investing
their
effort
in
their
side
of
the
product
and
then
how
that
impacts,
the
design
system
and
and
having
liked
a
similar
map
of
the
territory.
So
people
can
do
it,
so
I
won't
go
into
the
actual
video,
but
this
is
about
the.
C
This
is
the
accumulation
of
around
seven
months
worth
of
thinking
that
I've
had
and
I
feel
like
now,
it's
finally
getting
to
a
point
where
it's
not
just
verbose
and
ridiculously
hard
to
interpret
and
abstract
I
feel
like
now.
It's
actually
starting
to
get
to
a
point
where
people
will
hopefully
understand
that
I
don't
know,
maybe
I'm
going
crazy
after
seven
months
of
trying,
but
we'll
see
so
yeah
take
a
look
at
this
video.
C
Let
me
know
your
thoughts
and,
and
hopefully
this
will
also
be
a
useful
tool
to
align
our
efforts
around
different
disciplines
as
well
with
back-end,
front-end
and
design.
So
this
aligns
very
nicely
with
John
Mason's
generic
object
model.
Sorry,
generic
API
I
didn't
go
into
that
in
too
much
detail
in
this
video,
because
this
was
more
sort
of
design
focused
to
start
out
with,
but
I
can
I
could
probably
do
a
little
version
which
which
talks
about
that.
A
C
So
I
think
the
the
foundational
thing
with
this
object
model
is
its
describing
at
a
high
level
how
gitlab
works
in
using
objects
to
show
workflows
and
how
stuff
is
organized.
So
when
watching
the
video
in
the
back
of
your
mind,
maybe
think
if,
if
this
was
presented
to
my
to
my
parents,
would
they
understand
what?
What
at
a
high
level?
Would
they
understand
what
I'm
talking
about
and
then
also
think
about
gap
think
about
areas
for
opportunity
of
how
it
could
be
used
or
how
it
could
be
adapted
for
your
area
of
discipline.
C
Helpful
and
after
also
aligning
with
this
object
model
thing
that
I've
talked
about
I've
created
a
region
which
is
effectively
like
a
complicated
components,
and
this
is
like
a
grand.
This
is
trying
to
basically
unify
a
lot
of
the
disparate
components
that
we
have
a
got
across
gitlab,
and
it
does
this
by
having
like
a
basic
and
advanced
search,
filtering
pattern,
and
it's
best
illustrated
with
with
this
little
prototype
here.
I
think
we
can
still
simplify
this
down
further.
C
But
basically,
if
you
want
to
have
a
little
bit
more
space
on
the
page,
you
can
make
it
hidden.
If
you
don't
know
how
to
do
like
search
queries,
then
you
could
have
a
nice
little
easy
drop
down
experience,
and
if
you,
if
you
are
more
of
a
power
user-
and
you
know
how
to
do
these
queries,
you
can
have
it
in
that
format,
and
you
can
also
save
different
search
and
filter
combinations
in
a
filter
set
to
be
used
across
the
product
in
a
nice
and
quick
way.
C
So
this
is
a
little
bit
like
deep
linking,
but
also
applying
it
to
like
a
little
save
pattern.
So
this
is
the
first
stab
and
iteration
of
trying
to
unify
our
filter
pattern
across
gitlab
and
I'm
I'm.
You
know
I
think
there's,
there's
more
iteration
to
be
add
on
it
and
I'm
hoping
to
get
some
feedback
from
the
different
stage
groups,
but
yeah
interested
to
know
what
you
think,
how
complicated
would
be
to
implement
from
front-end
and
back-end
perspective.
D
E
I,
like
it
also
one
question
you
mentioned
about
storing
you
know
your
searches
or
your.
Your
theatres
I
see
a
few
potential
issues
there
from
security
point
of
view.
It
depends.
How
would
we
would
we
persist
it,
but
I
guess
we
would
have
this
paired
group
right.
So
if
you
have
a
tons
of
searches
in.
C
One
I
actually
haven't
thought
about
at
what
level
you'd
store
it,
whether
you
do
it
at
the
individual
level,
just
at
the
the
individuals
level
and
whether
it's
just
like
an
individual
has
their
own
sort
of
filter
sets.
I
actually
haven't
thought
about
it
to
that
level
of
detail.
So
that's
an
interesting
question.
Maybe.
D
I
can
provide
some
more
information
like
how
its
implemented
at
the
moment,
because
we
already
have
like
the
recent
searches
drop
down,
which
I
guess
works
in
a
similar
fashion
in
terms
of
how
we
persist
data.
So
at
the
moment
we
just
we
just
use
local
storage
on
the
front
end,
so
it's
not
going
through
the
API
at
all.
So
it's
not
persisted
on
the
back
end
and
then
the
way
it
works
at
the
moment
is
that
I
think
we
create
like
a
main
space
like
a
key
for
every
depending
on
the
URL.
D
So
if
you
are
in
a
specific
group
and
in
specific
project,
and
then
you
are
on
the
issues
page
based
on
the
on
the
route
that
you
are
on,
we
would
create
the
storage
key
for
the
local
storage
to
persist
the
recent
searches.
So,
if
you
go
to
like
a
different
group,
you
would
have
like
a
different
key
to
look
up
your
search
history.
So
that's
the
way
it
works
at
the
moment,
I
haven't
really
thought
about
I'm
gladder.
E
E
So
I
guess,
if
you
like
you,
bookmark
something
where
a
project
ID
is
pre-selected
right,
the
project
is
pre
selected
and
then
in
the
meantime,
you
are
removed
from
the
project.
Even
if
you
send
out
requests
to
the
backend,
you
will
get
a
photo
one
like
and
I
know
that
you
have
no
access
to.
So
that's
what
safer
than
actually
try
to
to
store
it
in
the
back
end
and
and
apply
permissions
there.
D
E
D
I
guess,
if
you,
if
you
clear
your
like,
if
you
clear
your
local
storage
or
yeah,
any
any
of
your
browser
data,
it
will
be
gone
so
you
want,
you
won't
see
any
of
this
in
the
recent
searches
drop-down.
D
So
it
it's
it's
up
to
you,
whether
you
wanna,
like
how
you,
if
you
want
to
clear
your
data,
I,
think
like
most
users
who
are
not,
we
don't
really
know
about
the
underlying
implementation.
They
probably
they
don't
really
care
about
it
so,
but
it
could
could
probably
it
could
lead
to
confusion
when
users
clear
the
local
storage
and
then
they
they
realize.
Okay,
all
my
searches
are
gone
so.
C
B
B
We
last
week
had
a
Forrester
briefing
they're
doing
their
next
wave
on
value
stream
management,
where
they
identify
vendors
that
are
in
different
levels
of
robustness,
with
their
offerings
and
vision,
and
that's
where
you
know
we're
really
getting
compared
to
competitors
and
so
on
and
they'll
probably
be
out
in
a
few
months.
Last
time
around
get
lab
was
about
18
months
ago.
I
say
get
lab,
did
surprisingly
well
for
the
level
of
capability
that
we
had,
but
I
think
are
sort
of
all
in
one
application.
B
Vision
is
unique
enough
that
it
got
us
some
attention
and
this
time
around
the
competitions,
gonna
be
quite
a
bit
stiffer.
So
I
would
expect
that
we're
gonna
slip
a
little
bit
in
the
ranking,
but
I
think
we're
well
positioned
to
come
back
strong
in
another
18
months
or
so
when
they
do
this.
For
the
third
time,
I
wanted
to
share
with
you
some
things
that
I
shared
with
the
analysts
just
a
couple
of
slides
to
help.
You
understand,
you
know
where
my
head
is
about
get
lab,
I.
B
Think,
as
you
see
on
this
slide,
there
are
a
couple
of
things
that
are
very
special
about
get
lab,
that
none
of
the
other
competitors
in
the
space
have
most
other
competitors
in
a
space
to
either
have
standalone.
Products
that
are
have
have
to
sit
on
top
of
a
collection
of
other
best-of-breed
software,
and
so
in
order
to
get
it
to
work.
You've
got
to
spend
quite
a
bit
of
time.
B
Mapping
and
integrating
it
and
analysts
are
very
interested
in
those
features
because
the
the
the
standalone
competitors
that's
exactly
the
way
that
they
work
and
sort
of
the
the
amount
of
openness
of
the
system,
and
a
number
of
integrations
that
you
have
are
important.
They're.
A
problem
with
those
is
that
the
time
to
value
is
very
poor.
B
It
takes
a
long
time
to
actually
get
the
thing
plugged
in
running
and
get
the
data
that
you
would
want
out
of
it,
and
the
other
problem
is
that
it's
not
really
part
of
users
everyday
workflows
and
get
lab,
because
we
are
a
single
app
that
people
are
already
using
every
day.
It
has
an
opportunity
both
to
to
do
very
well
in
terms
of
time
to
value
assume
this
I
flip
over
to
an
analytics
area.
B
But
it's
not
going
to
be
affecting
each
user's
everyday
decision-making
all
that
much
and
this
is
where
I
think
get
hat
get
lot
of.
It
has
a
huge
opportunity
to
actually,
through
the
use
of
analytics,
be
helping
every
single
user
every
day
as
they're
going
about
their
normal
work.
So
I
wanted
to
share
this
with
you,
because
the
way
that
we
have
thought
about
analytics
in
the
past
is
largely
about.
B
The
other
thing
I
think
that's
really
I'm
gonna
be
valuable
for
us
and
doing
that
is
it
won't
be
so
hard
to
get
people
to
use
analytics
instead,
it'll
be
right
there,
where
they're,
ordinarily
working
and
reach
for
it
where
they
can
reach
for
it.
There's
a
few
obvious
places
where
we
would
be
able
to
to
embed
analytics.
B
One
is
impersonal,
work
cues,
so
you've
seen
to
do
the
the
to
do.
Work
that
we're
exploring
another
is
in
visual
management
boards.
So
if
you
look
at
the
the
Kanban
board,
that's
in
get
lab
today.
You
know:
there's
lots
of
opportunity
for
analytics
to
actually
inform
what's
happening
in
that
experience
and
Nick
and
I
have
already
started,
collaborating
with
Gabe
Weaver
and
his
design
team
to
explore
some
opportunities
there,
and
then
customers
have
asked
for
analytics
related
to
a
product
and
program
management,
epics
and
roadmaps
and
stuff
and
there's
also
things.
B
Of
course
we
could
embed
in
individual
work
items.
We
can't
do
it
all
at
once,
but
these
are
the
kinds
of
experiences
that
we're
looking
at
making
richer
and
I
would
say
one
of
the
one
of
the
ones
that
really
stands
out
to
me
as
being
an
important
place
for
us
to
contribute
is
around
the
the
plan
area.
B
B
B
The
point
that
this
is
I'm
trying
to
get
to
here
is
that
the
these
embedded
experiences
will
be
less
expensive
to
build
and
also
more
flexible
if
they're
built
on
top
of
a
layer,
that's
more
generic
and
and
that's
one
of
the
things
that
we're
really
trying
to
focus
on
near-term
is
generic
api's
and
then
UI
elements
that
sit
on
top
of
that
that
leverage,
those
and
eventually
we
may
expose
that
capability
in
basic
dashboard
and
but
the
real
short
term
target
is
the
embedded
experiences
around
that.
So
the
first
step
of
that.
B
And
this
is,
if
I
were
to
trick
click
on
a
widget
that
had
a
metric
in
it
or
a
little
spark
line
graph
embedded
somewhere
else.
It
would
take
me
to
this
page
where
I
could
see
the
full-size
chart
and
the
data
table
beneath
it,
such
as
we're
doing
in
issues
analytics
today,
so
we're
working
on
refining
this
issue
to.
B
Be
a
complete
experience
that
will
be
pretty
flexible
so
that,
wherever
you
know,
whatever
you
know,
metric
I'm
or
sparkline
metric
card
or
sparkline
that
I'm
coming
to
you
know:
I
wind
up
landing
in
the
same
place
and
having
the
same
sort
of
experience
around
filtering
that
chart
and
exploring
it
and
so
longer
all
right,
I'm
sure
I've
used
more
than
my
fair
share
of
the
time.
So
I
will
pass
the
ball.
C
So
one
comment
on
that
drill
in
Page
is
with
the
the
object
model
that
I've
been
talking
about.
What
you
described
is
is
basically
a
report
object
so
and
then
this
report
objects
can
be
used
for
different
instances
for
issues
or
an
Mrs
or
whatever
it
may
be.
So
I
think
these
these
things
like
link
up
very
nicely
and
what
I'm
hoping
is.
D
Have
a
question
so
this
this
sounds
pretty
interesting.
So
as
far
as
I
understand
we're
like
moving
from
having
a
dedicated
analytics
page
into
like
enriching
existing
pages
or
areas
of
the
application
with
analytics
features
by
leveraging
the
generics
API-
and
this
is
like
obviously,
still
work-in-progress
and
a
quite
high
level
at
the
moment.
B
Well,
a
couple
of
ideas
that
have
come
to
mind
are
the
two
do's,
also
the
the
landing
page
for
groups.
You
know
we
have
some
recent
activity
metrics
there.
That
might
be
a
great
place
to
drill
in
continuing
to
work
on
the
issues
analytics,
page
and
sort
of
turning
that
into
a
generic
page
that
on
my
plate,
to
try
to
sort
out
at
this
afternoon.
Where
would
be
a
good
place
to
start?
If
you
have
opinions
about
that,
I'm
all
ears
and
I
would
love
your
feedback
on
that.
B
About
that
that
issue,
that
drill
in
Page
issue
is
going
to
start
getting
really
specific
about.
You
know
with
some
rough
wireframes
and-
and
so
you
know
very
specific
ideas
about
where
those
metrics
are
coming
from
and.
C
B
The
intent
isn't
is
not
to
you
know,
move
away
from
that
entirely.
I
think
that's
part
of
the
time
to
value,
but
we
also
need
to
take
take
a
little
pause
and
take
a
look
at
what
we're
doing,
because
some
of
the
calculations
that
we're
doing
on
that
page
are
problematic.
Some
of
the
we've
got
some
good
user
feedback
now
on
usability
issues
with
the
page,
so
we're
we're
gonna
kind
of
hit
a
little
bit
of
a
reset
working
with
customers
to
really
make
sure
we've
got
the
basics
working
before
we.
B
D
It
depends
if,
if
people
are
in
a
hurry,
we
can
always
postpone
it
to
next
week,
but
if
you
guys
have
a
few
more
minutes,
I
loved
you,
like
briefly
talk
about
those
topics.
I
always.
A
D
The
first
thing
was
a
question
about
so
we
developed
a
couple
of
analytics
features
over
the
last
few
months
or
over
the
last
year
and
including,
like
productivity,
analytics
code
reveal
analytics
and
obviously
value
stream
management
or
belly
stream
analytics,
and
the
question
is
we
build
like
it's
I
think
most
features
are
not
an
MVC
anymore,
but
the
idea
was
to
build
an
embassy
and
the
question
is:
are
there
any
plans
on
like
upcoming
iterations,
or
do
you
think,
especially?
The
question
goes
specially
to
John
Mason
from
a
product
perspective.
B
Great
thing,
thank
you
for
raising
that.
So
one
of
the
things
that
I've
been
doing
in
my
first
60
days,
it
get
up,
is
trying
to
understand
who's
using
our
stuff
and
what
they're
using
it
for
and
what
their
experience
has
been
like
and
I've
met
with
a
handful
of
customers.
I've
been
part
of
customer
advisory
board
meetings,
a
couple
of
customer
advisory
boarding,
board
meetings
where
we
talked
to
customers,
I've
worked
to
try
to
find
internal
users
and
talked
to
internal
users
about
their
usage.
B
B
B
There
are
a
lot
of
things
I
think
internally,
we
ought
to
be
using
analytics
for,
but
that
the
people
who
would
be
likely
consumers
of
those
have
felt
that
there
were
enough
shortcomings
in
the
capability.
They've
gone
and
built
duplicate
functionality
in
science,
and
that's
that's
not
good.
We
don't
want
internal
users
building
in
their
own
dashboards.
You
know
if
we've
got
it
baked
into
the
product,
so
I
I
started
an
epic
that
talked
about
you
know.
B
What
do
we
have
to
do
to
get
internal
users
to
use
our
stuff
more
and
as
I
started,
to
go
down
the
list?
One
of
the
things
I
noticed
was
that
there
are
things
that
would
be
required
kind
of
all
over.
Let
me
give
a
concrete
example.
One
of
the
things
that
users
internally
want
to
be
able
to
do
with
charts
is
embed
them
in
our
handbook
pages.
Another
thing
that
they
want
to
be
able
to
do
is
annotate
them
with
target
lines
well,
both
of
those
kinds
of
things.
B
If
you
look
at
all
the
kinds
of
charts
we
have
we'd
have
to
we'd
have
to
add
that
feature
in
a
whole.
Bunch
of
different
places
to
get
the
level
of
coverage
that
you
know
that
we
need
so
that
part
of
what's
motivating
some
of
this
generic
functionality
is
to
say,
listen.
If
we've
got
one
drill
in
page,
then
we
only
have
to
change
that
thing
in
one
place
and
we'll
be
able
to
get
we'll
be
able
to
get
to
internal
users
much
faster.
B
We
are.
We
are
going
to
be
taking
a
much
more
rigorous
approach
to
looking
at
how
customers
use
our
stuff
we're
implementing
a
Northstar
metric
along
with
all
the
other
product
teams
that
will
measure
the
weekly
active
users.
You
know
other
teams
are
doing
different
kinds
of
things.
What
we
will
be
measuring
is
weekly
active
users
for
our
our
analytics
capability
and
then,
when
we
decide
to
do
something
new,
the
idea
is,
we
will
have
users
in
mind
who
are
gonna
as
soon
as
it
comes
out
of
the
other
end
of
the
release.
B
We
know
they're
gonna
start
using
it
either
internal
users
to
start
dogfooding
it
or
external
users
that
are
working
with
us
in
a
partnership
so
that
that's
really
important,
because
otherwise
you
know
we
just
keep
building
things
and
and
people
come
and
they
look
at
them.
They
kick
the
tires,
but
but
then
they
go
away
and
we
we
don't
want
that.
D
Yeah
thanks
for
the
explanation
and
for
providing
more
more
context
and
motivation
behind
for
for
using
or
implementing
the
generics,
API
I
guess
part
of
the
rule.
For
my
understanding,
part
of
the
reason
why
contribution
analytics
might
be
the
most
used
feature
in
analytics
is
probably
because
it's
very
straightforward
and
easy
to
understand
so
I
guess
everyone
knows
what
contribution
means.
D
You
gather
it
click
on
the
page,
and
then
you
see
a
chart
or
like
multiple
charts
per
or
like
one
chart
per
user
which
which
gives
you
the
actual
number
of
contributions
over
time
for
that
particular
user.
So
I
guess
part
of
the
problem
why
other
analytics
pages
are
not
being
used
more
often
is
that
maybe
they
are
not
as
intuitive
as
contribution
analytics
or
people.
Don't
really
understand
how
this
analytics
feature
helps
them
in
getting
the
data
that
they
are
looking
for.
B
Yeah
I
think
part
of
it
is
just
knowing
it's
there
in
the
first
place
and
knowing
what
to
do
with
it
and
knowing
you
know
how
to
get
started
and
then
even
for
some
internal
users
that
are
more
willing
to
stick
with
it.
You
know,
because
we
have
a
lot
of
different
analytic
experiences.
We've
got
productivity,
analytics,
we've
got
contribution,
analytics,
we've
got.
You
know
all
these
different
things
knowing
where
to
go
to
find
what
they
need
is
also
hard.
I.
B
Think
when
we
have
more
of
a
generic
kind
of
library
of
metrics
that
you
can
add
to
a
dashboard
that
will
also,
you
know,
really
help
so
that
I'm,
not
you
know,
going
lots
of
different
places
and
then
that's
one
thing
that
would
really
help
the
field.
I.
Think
one
of
the
the
thing
that
the
few
things
that
the
field
struggles
with
is
they
get
customers
asking
them
hey
help
me,
you
know,
show
me
what
you
can
do
with
analytics
show
me.
B
You
know
help
me
make
a
development
dashboard
help
me
make
a
dashboard
for
my
executive
and
that's
very
hard
to
do
in
in
to
tell
that
story
and
get
love
today,
you
have
to
go
to
tons
of
different
pages
to
say.
Well,
we've
got
a
little
over
the
stuff
over
here
in
the
security
dashboard.
We've
got
this
other
stuff
over
here.
You
know,
and
these
analytics
features
and
we've
got
insights
over
here
and
it's
not
a
coherent
story.
B
D
Okay,
cool.
We
have
like
four
five
more
minutes
and
the
other
topic
that
I
just
wanted
to
bring
up
today
is
something
that
we
probably
learned
from
building.
Those
big
features
over
the
last
time
was
that,
in
my
opinion,
we
didn't
do
a
very
great
job
in
on
iteration.
So
we
built
those
big
features
which
took
us
more
than
one
or
two
milestones
to
finish,
and
in
the
meantime,
we
didn't
get
the
chance
to
like
gather
any
feedback
from
customers.
Whether
they
feature
is
gonna
be
useful.
D
So
there's
this
this
open,
iteration
issue,
I,
guess
to
then
open
it
thanks
for
doing
that,
then
I
guess
we
can
just
link
it
and
I
also
posted
it
in
the
analytics
channel.
So
I'd
love
to
hear
everyone's
feedback
on
this
particular
issue
in
terms
of
how
we
can
improve
iteration
in
the
future
and
what
are
the
the
things
that
we
learned
from
from
previous
mistakes?
And
maybe
we
can
pick
one
of
the
upcoming
issues.