►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
It's
funny,
because
I
actually
pulled
up
this
diagram
from
me
like
many
years
ago.
So
it's
kind
of
funny.
I
wanted
to
find
this
diagram
because
I
wanted
to
talk
about
when
to
use
data
in
the
sense
of
like
quantitative
data
and
like
what
questions
it
actually
helps
to
answer
we're
very
familiar
with
problem
and
solution,
validation,
questions
about
like
why
how
people
use
it
trying
to
figure
out
what's
missing
or
where
the
gaps
are,
but
on
the
flip
side
of
that
there's.
A
One
area
that
I
haven't
got
a
huge
chance
to
use
a
lot
until
maybe
a
couple
months
ago,
and
that's
the
quantitative
side
and
that's
looking
at
the
volume
of
things
being
used,
what's
being
used,
what's
being
clicked
on,
which
pages
are
being
viewed
and
that's
what
I
wanted
to
talk
about
today.
Kind
of
my
mini
journey
using
some
of
these
tools
here
at.
B
A
So
in
the
world
the
gitlab
problem
is
solution.
Validation,
like
I
said,
is
more
on
the
qualitative
side,
where
the
quantitative
side
is
actually
where
we're
looking
at
iteration,
where
we're
shifting
something
and
then
monitoring
it
or
taking
a
look
at
and
the
feedback
from
like
the
stats
from
events
and
other
things
like
that,
so
how's
data
being
captured
right
now
at
gitlab.
A
If
you
go
into
our
documentation,
you
can
see
you'll
find
this
diagram
here
of
how
data
is
being
captured.
All
I
was
exposed
to
was
size,
sense
dashboard.
So
that's
all
I
really
knew
and
I
was
just
trying
to
make
queries
from
there.
A
I
didn't
know
that
there
was
a
whole
system
behind
this,
of
how
this
actually
worked
and
for
me,
what
was
really
helpful
to
understand
was
kind
of
simplifying
this
diagram
into
looking
at
something
like
this,
where
we
have
our
data
infrastructure
layer,
which
is
science
and
that's
a
third-party
tool
that
you
may
be
familiar
with
by
looking
at
charts
or
tables
of
data
in
the
handbook
or
your
product
metrics,
and
that's
where
all
the
data
gets
aggregated
to
and
people
can
do,
queries
and
things
like
that
on
it
and
how
it
gets.
A
There
is
quite
interesting.
Snowplow
is
a
system
that
tracks
browser
events
as
well
as
on
the
server
side,
some
rails
events
are
being
tracked
through
there
as
well
and
that's
fed
into
the
database,
and
the
database
is
where
we
store
our
information
and
things
like
that,
and
that
information
is
also
available
in
size
sense,
but
more
commonly
that
information
is
aggregated
into
something
called
usage
ping,
and
this
gives
you
like
a
high
level
count
of
stats
that
you
may
care
about.
So
it
could
be
like
how
many
merch
comments
are
on.
B
A
Is
commonly
quoted,
I'm
essentially
thinking
about
like
aggregation,
and
what
we
can
see
with
the
pink
lines
is
that,
with
our
sas
service,
we
get
like
direct
feeds
from
snow,
plow,
usage
ping
and
the
database
straight
to
size
sense,
but
in
the
self-managed
instance
it's
just
usage
pings,
and
for
that
there's
a
delay
on
the
amount
of
data
plus,
like
not,
everyone
has
usage
being
turned
on
for
security
purposes,
so
they
might
turn
it
off
or
whatever
so
that's
kind
of
how
we
get
our
understanding
of
what
we're
actually
looking
at
when
we're
in
size
sense.
A
Like
I
said
this
is
kind
of
my
mental
model.
The
database
is
all
the
things
that
you
can
store
and
save
that
lives
there.
Usage
ping
lives
is
derived
from
any
information
from
the
database,
so
its
aggregation
is
the
total
number
of
issues
count
of
distinct
users,
creating
issues
any
kind
of
settings
aggregation
like
how
many
may
have
how
many
sites
have.
A
This
thing
turned
on
and
that's
kind
of
where
usage
ping
excels
at
and
then
on
the
other
side
we
have
snow
plow,
and
that
gives
us
structured
events
so
like,
for
example,
if
registration
completed
and
that's
a
back-end
event
that
gets
registered
through
snowplow
on
the
browser.
If
you're
clicking
on
a
menu
item
or
things
or
a
button,
then
that
could
be
triggered
through
snowplow
or
captured
through
snowplow
map
and
page
views
as
well
within
the
product
is
tracked
through
snowplow.
A
So
we
have
this
left
bar
side
left,
sidebar
interaction
and
at
the
moment
we
have
the
ability
to
both
click
on
the
parent
menu
item
to
go
to
the
page.
But
we
also
have
the
ability
to
hover
on
the
parent
menu
item
which
opens
up
a
sub
menu
and
you
can
click
on
that
to
go
through.
A
This
is
a
behavior
that's
been
around
since
I've
joined,
get
lab
and
it's
actually
like
way
back
to
2017
when
it
was
first
introduced
and
it's
basically
how
people
interact
with
github
now
and
as
we're
looking
through
this
interaction,
we
kind
of
wanted
to
see
if
it
was
an
opportunity
to
potentially
change
it
or
remove
it,
but
before
we
wanted
to
do
that,
I
wanted
to
see
like
what
the
breakdown
was
between
like
how
many
people
actually
click
on
the
first
menu
item
versus
the
parent
menu
item.
A
And
does
this
behavior
differ
when
it's
collapsed
or
expanded,
because
this
feature
was
introduced
for
speed
and
efficient
like
speed
and
efficiency
for
users
who
use
like
mouse
as
a
their
pointing
device?
A
So
if
we
take
a
step
back,
we're
looking
at
click
events
here
and
for
click
events,
there's
a
certain
way.
We
define
these
events
and
that's
called
the
schema
and
it's
broken
down
to
a
structured
event
and
out
of
the
box
with
snowplow.
They
give
you
some
default
context.
So
this
is
the
browser,
the
os
and
things
like
that,
and
then
the
data
team
has
added
on
git,
lab
information
like
the
environment
and
project
id
and
namespace
what
we
as
designers
and
product
people,
what
we
care
about
is
more
in
the
structured
event.
A
And
they're
being
tracked
and
the
naming
conventions
of
those,
but
I'm
skipping
that
for
the
purposes
of
this
showcase,
what
we
did
was
then
kind
of
broke
it
down
between
myself
the
engineer
my
group
fran
and
members
of
the
data
team
to
understand
okay,
this
is
the
these.
Are
the
different
states
that
we
want
to
capture.
These
are
the
different
events
that
are
being
populated,
and
this
is
the
extra
information
that
we
wanted
to
capture
to
capture
things
to
the
same.
C
A
The
person
clicked
it
on
the
menu
while
I
was
in
the
flyout
state
or
they
clicked
on
the
sub
menu
item.
So
these
different
combinations
were
discussed
amongst
the
three
of
us
as
well
as
the
pm.
So
it
was
a
good
story
of
a
collaboration
here
because
for
us
it
was
the
first
time
diving
deep
into
snowplow
events.
So
it
was
a
good
learning
experience
for
our
group
as
well,
and
once
that
was
done,
we
gathered
all
the
information
and
I
used
sisense
to
create
tables
of
getting
information.
D
A
We
were
able
to
do
was
then
compare
direct
clicks
on
the
parent
menu
item
versus
the
first
submenu
item
when
it
was
expanded
and
we
can
see
that
when
expanded,
the
parent
menu
item
actually
got
more
clicks.
Direct
clicks
versus
the
first
sub
menu
item
when
the
flyout
menu
was
displayed
and
whether
people
used
the
nested
view.
So
that's
when
the
you
can
see
the
sub
menu
within
the
left,
sidebar
or
the
flyout
state
that
was
actually
kind
of
similar.
A
A
B
A
You
know
what
could
be
the
root
cause
of
this,
and
this
is
where
we
kind
of
look
back
at
the
qualitative
side,
and
this
whole
balance
of
qualitative
and
quantitative
is
where
I
like
to
see
us
grow
more
as
a
designer
organization,
there's
a
huge
opportunity
for
this,
where
we
can
use
both
to
balance
each
other
over
time.
E
A
So
where
I
see
my
kind
of
thinking
about
data
right
now,
is
that
it's
both
qualitative
and
quantitative,
where
one
feeds
questions
into
the
other
and
the
other
feeds
questions
into
the
other.
And
it's
just
in
the
cycle
of
iteration
and
validation
and
fun
fact.
While
I
was
doing
this,
I
realized
that
my
manager
told
me
that
designers
are
actually
not
supposed
to
have
access
to
sizes
yet
so
that
might
get
revoked
for
me
soon.
But
for
those
interested
in
learning
more
about
data
and
myself
as
well.
A
These
are
some
useful
resources
to
look
at
in
the
near
term.
Data
for
product
managers,
it's
a
page
in
the
handbook
that
kind
of
breaks
down
understanding
how
our
data
works
and
like
what
kind
of
things
those
are
useful
to
learn
and,
in
the
meantime,
I'm
working
on
a
page.
In
the
handbook
about
data
for
designers
and
yeah,
if
you
have
any
questions
or
comments
in
that
space
feel
free
to
leave
a
comment,
it's
still
early
days
there,
so
I
hoping
you
all
once
it's
more
refined.
Thank
you.
D
This
is
amazing
thanks
so
much
for
sharing
michael,
that
really
inspired
me
to
follow
a
similar
process
with
my
pm
and
try
it
out
because
we're
currently
in
the
process
of
instrumenting
the
pipeline
authoring,
onboarding
workflow,
and
so
I
think
it's
perfect
timing
for
us
to
start
thinking
like
what
are
we
going
to
do
next
and
what
data
what
else
is
available.
D
A
Yes,
I
think
there's
a
lot
of
resources
out
there
to
get
up
to
speed,
there's
training
and
certificates
that
you
can
try.
So
these
are
like
one
page
or
handbook
pages.
That
kind
of
gives
you
like
a
high
level
of
how
to
write,
queries
and
things
like
that.
So
you
do
you
read
some
of
that
and
fill
out
like
the
quiz
and
then
yeah.
E
B
Yeah
I'll
voice,
my
fyi,
my
comment
so
michael
mentioned
that
yeah,
not
everyone
will
get
access
to
two
citizens.
So
if
you
need
to
create
dashboards,
make
sure
you
reach
out
to
someone
that
has
editor
access.
That's
usually
product
managers.
As
far
as
I
know,
I
don't
have
access
myself
and
marcel.
E
Very
small
edition,
but
we
also
have
a
very
strong
data
team.
That's
already
in
place.
They
are
small,
so
sometimes
you
may
need
to
wait
a
bit
because
they
are
probably
overloaded
with
requests,
but
if
you
want
to
connect
directly
with
them,
posting
something
in
the
data
channel
on
slack
is
a
very
good.
C
Idea-
okay,
I'm
next,
so
I
just
wanted
to
mention
that
I
mean
I
also
had
this
conversation
with
jackie
inspired
by
michael,
because
we
have
our
constant
butterfly
chats.
So
she
shared
a
lot
many
dashboards
with
me
that
I
am
now
looking
at
and
I'm
trying
to
understand
how
to
make
the
best
use
of
that.
But
we
also
created
a
merge
request
to
make
a
small
change
in
our
process.
So
it's
just
to
ensure
that
we
are
also
taking
into
account
some
known
data
that
we
have
during
our
validation
tracks.
A
Us
thanks
for
sharing
that
physical,
I
think
that's
useful
for
the
long
run.
F
Yeah
thanks
michael
yeah.
This
is
this
is
something
that
I
was
hoping
someone
made
a
presentation
and
it's
a
very
important
topic
for
designers
to
make
better
decisions,
and
I
think
that
a
lot
of
a
lot
of
product
managers
use
data.
F
But
my
personal
experience
is
that
they're
not
as
interested
in
the
granular
usage
data
as
much
as
we
are
and
and
it
can
provide
some
clarity
on
the
larger
metrics
that
we
usually
track
the
monthly
active
users,
and
things
like
that.
So
I
think
it's
very
timely.
Thank
you
for
for
the
presentation
and
specifically
the
work
that
you
did
with
your
team.
I
think
the
any
any
of
the
events
and
and
clicks
that
you
instrumented
are
helpful
for
any
group
at
gitlab,
but
for
me
specifically
and
code
review.
F
Thank
you
for
instrumenting
and
doing
the
work
of
instrumenting
the
top
links,
especially
the
issues
mrs
introduced,
because
that
will
help
us
improve
the
way
that
people
find
your
merge
requests
so
yeah.
This
was
more
of
a
statement
mike
one
question
that
I
had,
and
I
was
starting
to
write
it
down
in
the
agenda-
was
that
I'm
not
entirely
sure.
I
haven't
found
anything
in
the
handbook,
but
maybe
there
is
is
if
we
are
allowed
to
publicly
share
screenshots
and
numbers
of
the
usage
data,
I
don't
know
in
the
past.
F
F
F
E
A
F
And
then
maybe
this
presentation,
because
I
think
you
you
showed
some
some
numbers,
I'm
not
sure,
but
anyway
yeah.
I
think
this
is
this
is
great
and
thank
you
so
much
for
explaining
this
and
and
now
we
know
who
to
to
nag
if
we
want
to
help
with
the
dashboards.
B
I'll
check
the
guidelines
from
now
on,
I
think
that's
a
good
heads-up
awesome,
any
other
questions
right
then
I'll.
Stop,
recording
and
thanks,
michael
for
the
presentation.