►
From YouTube: Product and Data folks talk about analytics strategy
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
Okay,
so
we
are
recording,
so
the
agenda
is
there
in
the
invite,
so
is
Jeremy
here,
yeah,
so
Jeremy.
Do
you
want
to
talk
about
your
point
for
us
because
it's
obviously
more
relevant
because
we
should
start
at
the
problem
and
not
jump
to
solution.
So
why
don't
you
start
and
then
we
can
jump
into
solutions?
Yeah.
B
We
don't
have
to
like
fight
that
and
then
three
be
able
to
follow
outcomes.
We
ship
something.
We
understand
what
they're
like
outcomes
with
like
that
thing
is
so
I
guess.
My
question
is
like
do
we
feel
like
we're
able
to
do
that
with?
Like
the
current
set
up,
we
have,
which
is,
we
have
usage
ping
and
we
have
snowplow
on
like
self-managed
and
calm
respectively.
We
have
that
all
go
to
a
data
warehouse
and
then
well
or
be
able
to
explore
that
visualize.
B
That
now
with
periscope,
so
is
that
going
well
like
is
our
current
approach.
Solving
like
those
and
product
needs
that
I
kind
of
talked
about
it
like
do?
We
need
to
like
make
a
radical
changes
so
that
approach
or
do
we
need
to
like
just
kind
of
make
tweaks
to
like
the
approach
that
we
already
have,
and
that's
kind
of
the
thing
I'm
really
curious
about
and.
C
I'll
add
the
caveat
to
that
Jeremy
of
the
specifics
around
the
snowplow
implementation
that
we
are
not
tracking
individual
user
data
right
now,
because
it's
still
unshared
infrastructure
and
so
we've
limited
what
we're
tracking,
which
has
been
a
point
of
frustration
for
some
of
the
product
managers
in
the
past.
And
we
need
that
to
move
forward.
If
we
want
to
actually
be
tracking
everything
on
background
I
totally.
B
What
how
to
use
this
or
have
you
like
gone
past
that,
like
you,
actually
tried
to
like
write,
queries
and
then
been
unimpressed
with
the
data,
because,
if
that's
the
case
then,
like
maybe
the
snowplow
fidelity
like
we
can
ramp
that
up
and
try
to
solve
that.
But
if
it's
more
the
former
than
like,
we
wouldn't
be
able
to
fix
that,
but
with
like
snow
paw
improvements,
so
maybe
we
can
start
there,
which
is
like
product
managers.
Have
you
have
you
use
data
like
at
gitlab
like?
A
But
we
can't
do
the
opposite,
because
that
they'll
be
terrible.
So
we
we
purposely
set
the
limit
to
5,
and
then
we
tracked
the
data
to
say:
are
people
actually
going
to
up
to
5
and
it
turns
out
the
data
indicates
that
people
are
using
like
1
or
2
at
most
and
maybe
sometimes
3
levels,
but
not
going
much
more
beyond
that.
So
that
was
a
very
specific
usage
of
the
usage
ping.
That
was
helpful,
but
that's
definitely
not
the
norm
most
of
the
time
it
is
not
driving
product
decisions
as
I
want.
D
Personally,
I
found
probably
looking
at
usage
pink
data.
I
have
some
four
security
features,
but
the
problem
is
that
is
very,
very
high
level,
so
we
just
count
jobs,
for
example,
for
SAS
and
that's
dependencies
cannae
depth,
something,
but
that's
probably
not
giving
us
the
idea
how
users
are
using
those
features,
and
we
mainly
know
it
at
all.
South
DevOps
was
running
a
lot
of
those
pipelines
automatically.
So
it's
not
really
an
idea
how
much
users
are
involved
with
our
features?
D
What
I
found
very
very
useful,
even
if
I
cannot
collect
data,
but
that's
the
different
story.
Is
this
no
bloat
because
mainly
I
want
to
know
how
much
users
know
click
on
a
specific
button
or
expand
the
merge
request
security
panel
and
that's
what
I
already
need
to
know
so
I,
don't
care
how
much
data
is
produced
at
the
beginning,
but
how
much
data
is
consumed
at
the
end
and
finally,
snowplow
is
available
only
for
get
logged
calm
as
far
as
I
know.
D
Otherwise
you
make
me
happy,
but
I
so
I
know
that
there
is
some
plan
to
do
sort
of
snow
blow.
Data
for
on-prem
and
security
features
mainly
are
used
by
ultimate
customers
and
they
have
on
prime
or
self-managed
that's
corrector
and
installations,
so
I
can
get
data
from
Gilad
calm,
but
death,
not
really
our.
You
know
our
use
case
our
standard
customer
that
we
want
to
monitor
on
google.com.
We
have
also
public
projects
that
can
use
ultimate
features
for
free,
but
that's
not
the
target
we
want
to.
D
C
I
just
want
to
make
sure
I'm
understanding
correctly.
What
I'm
hearing
from
Victor
is
that
when
the
data
you
want
is
available,
it
is
useful
in
driving
your
decision-making.
But
what
I'm
hearing
from
vo
is
that
there's
still
frustration
about
cutting
the
data
that
you
need
to
make
those
decisions
and,
in
your
specific
case,
with
the
secure
features
it
just
so
happened
that
the
customers
that
are
most
valuable
to
you
are
not
being
tracked
by
snowplow
in
the
structure
of
the
usage
ping,
which
I
think
we're
all
familiar
with
is
just
an
infinite
counter.
D
C
B
Know
it
there
is,
but
I
would
imagine
that
it
was
very,
very,
very
hard
to
get
instances
to
opt-in
to
it
because
they
were
just
there's.
There's
a
word.
There
would
be
a
ton
of
data
like
that.
We
were
hitting
that
the
hammering
the
collection
point
would
be
very
easy
for
someone
to
turn
that
off.
I
think
that
like
so,
we
can
definitely
try
that
like
there's.
B
I,
don't
know
how,
if
there's
like
the
opportunities
for
us
to
like
either,
you
know
bash
that
or
like
some
more
like
summarize
that
data
so
like
we're
like
not
hammering
our
endpoint
and
like
sending
traffic
and
like
making
it
very
easy
for
someone
to
turn
that
off,
but
I
also,
but
I
think
it
was
really
interesting
for
me
to
hear
from
Fabio
like
the
types
of
information
that
are
really
useful,
because
I
agree
like
for
me.
You,
since
ping,
is
just
like
so
high
level
that
it
is
it
is
it
is,
you
know
it.
B
We've
tried
to
anonymity
like
nerf
it
to
the
state,
to
a
state
where
it's
like
digestible
for
users,
but
it's
not
really
working
for
the
product
team
either
we're
not
getting
like,
as
nearly
as
much
out
of
that
as
we
need
to
like
it's
totally
possible
for
us
to
increase
the
fidelity
of
usage
of
the
usage
data,
and
so
like
every
day.
We're
like
summarizing
like
the
stuff
that
people
are
clicking
on,
and
you
know
we're
sending
that
on,
like
a
daily
basis
like
to
get
for
instance,
and
Mike's.
D
Improvement,
yes,
sir,
as
far
as
I
understand,
it's
not
possible
to
have
on
pram,
so
self-manage
snow,
blue
infrastructure,
so
they
will
still
use
our
own
infrastructure
to
to
send
data
to
it.
So
that's
probably
a
blocker
for
for
this
to
happen.
Is
there
any
way
that
you
can
influence
something
in
the
product
that
is,
you
know
snow
blow
like,
but
very,
very
light
that
will
allow
to
count.
D
B
I,
don't
see
why
not
like
I,
don't
know
why
we
couldn't
create
like
a
new
table
and
then
every
time
someone
clicks
a
button.
You
know
we
increment,
like
we
sent
that
event
and
store
that
in
the
table,
and
then
you
know
summarize
that
you
know
that
you
know
he
said
you
know,
statistics
table
or
whatever
everyday
and
then
so
run
a
job,
some
that
information
up
until
like
a
blob
and
then
sit
off
to
get
loud,
I,
don't
know
why
we
couldn't
do
that.
B
C
Want
to
caution,
though,
the
idea
of
like
let's
check
this
one
way
for
on-prem
customer
self-managed
customers
and
let's
check
this
another
way
for
staffs
customers
that
what
you're
then
going
to
write
once
we
track
that
way.
The
next
question
is
going
to
be:
let's
make
an
analysis.
That's
gonna
put
these
customers
next
to
each
other,
and
what
we're
gonna
find
is
there
are
inconsistencies
in
the
data
or
incongruencies.
A
Well,
I'll
push
back
and
you
push
back
so
there's
a
couple
things
there
like
I
think
we
need
to
do
what
we
can
now
so
there's
the
iteration
point
with
on-prem
I
think
it's
a
tall
order
to
do
the
technical
solutions,
because
I
would
see
just
from
like
open
source
and
getting
opt-in
and
people.
Agreeing
to
that
I
think
it's
it's
pretty
risky
I
think
we
may
have
had
similar
discussions
in
the
past.
So
the
way
I
see
it
is
in
the
short
term.
A
We
it
would
be
pretty
unlikely
to
get
front-end
data
from
on-prem
and
so
I
wouldn't
want
to
optimize
to
do
need
to
do
that
and
this
or
if
you
get
a
front-end
data
from
comm,
it
will
be
like
a
like
a
red
ship
style
thing
or
a
streaming
thing
and,
and
it
wouldn't
be
the
the
on-prem
solution
and
I
think
that's:
okay,
because
I
see
the
on
print
solution
being
so
far
away
and
then
to
address
Fabio's
point
on
the
data
would
be
different.
Internship
and
reser
point
Emily
as
well
from
a
business
perspective.
A
Thus,
the
customers
are
different
from
both
places,
but
I
think
that's
just
what
we
have
to
work
with.
We
have
two
lines
of
business
right
now:
calm
and
self
hosted
and
calm,
there's
less
customers,
it's
less
representative
and
so
I
would,
as
a
program
manager,
use
that
data
to
to
do
like
the
UI
interactions.
I
think
that
would
be
a
pretty
good
thing
to
use
from
a
product
perspective
to
drive
a
feature
and
then
I
would
rely
on
the
on-prem
data
to
drive
to
understand
adoption
more
widely
and
driving
real
dollars
and
cents
decisions.
A
D
And
also
I
just
think
about
that
one
of
the
problems
and
that's
why
I
say
before
no,
we
have
an
implementation
problem
because
I'm.
Finally,
a
lot
of
logic
is
now
in
the
front
end
for
the
security
features
and
that's
a
problem
mostly
because
it's
very
hard
to
collect
any
usage
being
more
than
the
number
of
jobs
for
a
bunch
of
things
we
are
working
and
the
plan
is
to
move
a
lot
of
this
logic
and
code
in
the
backend.
D
Probably
at
that
point
it
would
be
easier
to
create
objects
and
counters
that
can
be
introduced
can
be
added
to
the
usage
ping
data.
So
at
that
point
you
can
count
how
many
times
an
endpoint
that
creates
that
node.
If
report
in
the
merge
sucrose
widget
is,
is
a
cold,
and
so
we
have
the
information
that
we
need
without
using
a
snow
blow,
but
using
the
back
end
thing:
I
have
this
problem
now,
but
you
know,
is
a
shared
responsibility:
I'm,
not
saying
it
because
of
only
their
use,
its
being
infrastructure.
B
Was
gonna
make
a
point
that
I
agree
with
your
points?
Victor
I
do
think
that
as
get
lab,
comm
can
use
to
grow
like
are
paid.
Users
continue
to
go
up
into
the
right
like
that,
will
increase
in
the
quality
of
the
data.
The
you
know
yes,
I
understand
like
most
secure.
Customers
are
like
on
ultimate
and
their
own
self
managed
that
way,
that
will
you
know
that
that
user
base
will
grow
in
quality
and
will
be
able
to
get
more
and
more
insights.
From
up
my
pain
usage,
like
from
that
user
base
right
number.
A
B
A
C
E
D
F
F
It
would
be
a
good
step
to
at
least
in
at
least
in
product
start
thinking
about
the
kind
of
question
that
we
want
to
ask
off
the
data
like
if
it
doesn't
matter,
if
it
doesn't
exist
like
what
is
it
B,
you
want
to
ask
of
like
Fabio
what,
in
the
secure
stage
like
what
are
the
things
that
you
want
to
know
from
the
features
that
you're
implementing
and
how
people
are
using
it
like
and
work
backwards
from
there
like
what
is
it?
What
is
it
an
ideal
dashboard
look
to
you
what
it?
D
F
D
F
C
Is
helpful
but
they're
not
they're,
not
comp.
These
are
not
conversations
that
need
to
happen.
Sequentially
their
covers
need
to
happen
in
tandem
so
like
in
terms
of
how
do
we?
What
is
your
ideal
state
of
the
product
team
being
data-driven,
we're
being
data
informed
like
that
is
definitely
one
conversation
that
needs
to
happen.
Another
conversation
that
needs
to
happen
is
given
the
existing
constraints.
How
can
the
data
team
help
product
achieve
its
goals?
C
C
C
Everyone
is
on
the
same
page
right
now,
given
the
constraint
of
the
usage
pane,
adoption
is
really
just
running
the
jobs
I
built
a
dashboard
for
Fabio
last
week,
and
it
really
is
just
a
count
of
jobs
and
we
do
our
best
with
the
data
we
have
to
make
it
useful
understand
what
the
average
trends
are.
What
the
month
over
month,
growth
are
but
like,
we
have
to
work
within
existing
constraints,
and
so
I
don't
disagree.
Lucca,
like
what
does
the
organization
look
like
I?
C
Think
you
late
the
issue
that
Jeremy
created
yesterday
I
think
it's
a
great
conversation
to
have,
but
we
can't
lose
sight
of
we.
We
can't
favor
that
conversation
of
what
does
this
look
like?
What
should
it
look
like
in
at
the
cost
of
losing
the
conversation
of?
How
do
we
work
within
existing
constraints?
Yeah.
F
C
So
this
is
a
secure,
metrics
dashboard
that
I
created
loosely
based
off
something
that
already
existed
in
looker.
It's
still
gonna
use
a
lot
of
polishing,
but
just
a
tldr
of
what
you're
looking
at
there's
a
date
range
filter
here,
pingzhi
that
can
be
outfitted
after
weekly
or
the
monthly
levels
and
then
quarterly
and
yearly
of
course,
and
if
you
change
the
animation,
it
does
reflect
the
data.
Now
there
are
some
problems
with
the
pings
data
itself.
C
When
we
look
at
it
on
a
weekly
level,
you
can
see
things
like
clearly
here
we
didn't
get
any
pings
for
these
features.
Clearly,
here
we
didn't
get
all
the
pings.
We
know
that
pings
is
always
up
into
the
right.
So
when
we
see
these
gaps,
we
know
that
there's
gaps
in
the
data
we're
working
on
how
to
identify
that
a
little
bit
better
on
the
data
team,
but
right
now
like
this
is
how
you
can
tell
that,
and
then
you
can
see
things
like
rolling
average,
weekly
growth,
etc.
C
If
we
go
back
to
the
monthly
level,
the
one
thing
I
want
to
highlight
so-
and
we
mentioned
this
in
the
handbook,
but
one
you
know
people
can
requests
equal
access
to
periscope
and
I've
created
a
function
here.
One
fun
function,
feature
usage,
this
aggregation
period
and
growth.
That's
going
to
allow
you
and
all
you
have
to
do
is
and
your
features
name
from
the
usage
ping
and
it's
going
to
allow
you
to
build
that
all
of
this
whole
dashboard.
C
B
Don't
to
be
honest,
I
haven't
spent
much
time
in
periscope,
so
I
don't
know
how
easy
it
is
to
like
fork
that
dashboard
and
then
to
make
one
of
one
for
my
own
for
manage,
but
I
love
the
example
like
I
love,
having
example
to
be
able
to
riff
off
them,
but
I,
don't
know
how
challenging
it
is
in
periscope,
because
I
haven't
done
it.
You
know
I
had
opinions
outlook
a
bit
of
those
are
relevant
so.
C
B
C
Is
coming
and
so
I
announced
this
today,
training
is
coming.
We
will
announce
the
training
when
we
have
it.
There
is
documentation,
I
will
drop
the
link
in
the
agenda
and
you
know
you
can
run
from
there.
It
is
pretty
intuitive,
but
it's
worth
spending
the
twenty
minutes
to
watch
the
onboarding
video
to
scratch.
Your
head
a
little
bit
less
down
the
road.
B
Cool,
that's
awesome,
so
we
have
an
extra
native
there
to
kind
of
dive
into
periscope
a
little
bit
we're.
What
are
the
next
steps
kind
of
like
on
the
data
collection
side
in
terms
of
like
the
new
version
of
usage
King?
Was
it
to
kind
of
create
like
the
secure
kind
of
mock
dashboard
in
terms
of
like
the
things
that
we
wanted
to
kind
of
capture
and
then
to
kind
of
like
consider
a
product
kind
of
path
that
allows
us
to
get.
There
did
I
get
that
right.
E
So
one
of
the
things
that
has
worked
really
well
for
me
in
the
past
is
just
having
an
instrumentation
sheet
of
the
kind
of
questions
that
you'd
like
to
answer
and
then
having
the
events
that
you
would
need
to
be
able
to
answer
those
questions.
And
that
gives
you
a
visualization
of
clearly.
There
will
be
some
things
that
are
not
technically
feasible
for
implementation
and
you
would
mark
those
is
not
able
to
implement,
and
that
gives
you
the
gaps
in
that
you
don't
have.
E
Obviously
that's
that's
ideal.
One
of
the
one
of
the
questions
that
I
have
in
terms
of
refactoring
the
pings
has:
has
there
any
analysis
been
done
in
the
past
time?
I'm.
Sorry,
maybe
it
has
on
how
different
good
laptop
conferences,
self
managed.
Users
are
because
the
question
remains
of
how
how
am
important
in
terms
of
product
positions
is
self-managed.
B
Self-Managed
customers
and
our
user
base.
There
is
very
different
from
calm
at
the
moment.
Most
the
vast
majority
of
our
business
comes
from
self-managed,
so
it's
very
important
at
the
moment
for
asked
us
to
understand
self-managed
at
a
very
detailed
level
more
than
com.com.
Obviously
we
control
that
instance
and
we
can
send
whatever
information
that
we
want
to
back
to
you
I
think
so.
B
Fidelity
of
the
amount
of
data
we
can
capture.
You
know
we're
more
leeway
there.
Her
self-managed
were
reliant
on
these
self-managed
instances
to
send
data
and
voluntarily
about
to
get
lab
Inc.
So,
but
if
I
could
wave
a
magic
wand,
I
would
love
to
have
perfect
knowledge
of
her
self-managed
right
now.
Today,
Jeremy.
D
I
have
to
agree
and
disagree
at
the
same
time
with
you,
let's
say
so.
For
me,
a
specifically
for
secure
eyes,
you
already
know
calm,
is
not
really
useful.
It's
very
very
useful
check
on
pram,
but
I
also
feel
that
you
know
from
gillip
calm.
We
can
get
no
new
trends
and
people
that
want
to
experiment
things.
So
maybe-
and
it's
also
it's
very
hard
to
get
and
I
talking
about
the
stages
that
have
a
lot
of
you
know.
D
Community
life
facing
features,
it's
not
so
easy
to
get
feedback
from
individual
contributors
or
open
source
projects,
while
it
is
way
easier
to
get
it
from
on
self-managed
customers,
for
example,
from
ultimate
that
you
may
have
no
five
customers
that
you
can
ping
regularly.
You
can
get
a
lot
of
feedback
from
their
and
and
they
are
covering
a
lot
from
the
self
hosted
different
self
manage
instances
when
angular
that
come
there
are
a
million
of
individual
contributors.
You
cannot
be.
D
You
cannot
get
in
contact,
they
have
no
time,
no
interest,
no
knowledge
that
you
want
to
get
some
information
for
them.
So
I
see
a
value
knowing
calm
on
this
specific
task,
even
if
I
agree
that,
obviously
our
self-managed
are
the
core
that
they
are
giving
us
the
idea
how
to
know
how
to
increase
our
revenues.
That's
you
know
in
pragmatic
world
the
water
where
they
can
give
us
I.
G
Wanted
we've
got
one
minute:
can
I
just
jump
in
real,
quick
I'm
curious
how
much
support
product
you
are
looking
for
around
the
data
collection
question
it
seems
like
we
can
be
really
helpful
for
the
what
data
we
want
to
answer
standpoint.
I
think
we've
got
our
own
takeaways
on
our
side,
but
in
terms
of
supporting
me,
how
do
we
want
to
collect
this
data
both
on
Prem
and
comm?
Would
you
like
us
to
go
through
that
with
you?
Would
you
like
us
to
help
drive
that
what
would
be
helpful
for
for
you,
I.
B
Don't
I,
don't
care
like
I,
if
there's
room
for
for
your
team
to
kind
of
help
out
with
the
shape
product
changes
or
they
have
the
lifting
in
order
to
make
that
happen.
I'm,
like
all
for
it
but
I
guess
I
would
leave
that
up
to
maybe
Lucca
to
kind
of
kind
of
drive
and
help
define,
and
then
we
can
kind
of
see
how
we
can
accelerate
that
plan.
So.
G
There's
a
like
the
infrastructure,
let
me
jump
on
that
piece.
Real,
quick
I
was:
we
ran
out
of
time,
so
I
wasn't
gonna,
get
to
it,
but
there's
there's
a
takeaway
on
the
data
team
side,
which
is
it's
sort
of
already
obvious,
but
there's
a
big
paradigm
shift
coming
in
terms
of
where
the
bulk
of
our
data
and
where
the
bulk
of
our
data
beets
are
are
coming
from
it's
about
to
shift
heavily
to
product
I
sort
of
according
to
these
conversations,
and
so
we
need
to
take
a
step
back
and
say:
alright.
B
G
C
F
Just
a
quickly
on
to
Emily's
question
about
where
the
infrastructure,
where
the
responsibility
for
the
infrastructure
and
I
don't
think
it's
performant
at
this
point,
I
think
it
will
stay
with
the
data
team
that
may
change,
I,
don't
know
and
I,
but
for
the
foreseeable
future
I
think
it
will
still
say
with
you.
But
if
that's
something
else,
it's
not
with
us
now.
Oh
it's
not
right.
Now.