►
From YouTube: 2022-08-08 Analytics Section Meeting
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
Hey,
oh,
hey
everyone,
so
we
have
a
proposal
to
have
a
knowledge
sharing
session
from
Jay.
Jay
was
working
to
recently
with
the
servicing
data
and
he
was
sharing
some
interesting
analysis.
There
I
I,
think
that
would
be
interesting
for
everyone
to
to
participate.
Next
Step
would
be
to
set
up
a
timing
for
this
session
and
there
is
an
issue
there.
Please
have
a
look
with
the
link
to
the
work
that
he
was
doing
and
maybe
at
some
topics
that
might
be
useful
for
the
presentation,
preparation.
B
I,
like
that,
yeah
I,
like
the
idea,
a
lot,
especially
as
including
myself,
we
have
a
lot
of
newcomers
to
the
topic,
especially
to
service
ping
and
all
the
implementation
and
I
think
that
would
be
a
great
start
to
actually
figure
out
that
how
we
can
transform
topics
also
to
service
ping
and
leverage
things
here
and
there
and
what
to
build
into
the
product
and
what
to
leave
custom
I
think
they
are
still
of
a
lot
of
topics
left
to
figure
out
along
the
way.
B
Good
then
I
believe
I'm
next
I,
intended
in
the
way
that
I
would
have
another
topic,
but
I
actually
hadn't,
so
I
just
make
it
like
this.
So
a
huge
topic
that
that
I
think
is
still
very,
very
open
and
I
would
love
to
hear
everyone's
inputs,
and
that's
why
I
haven't
added
it
to
any
sort
of
issue
so
far,
because
it's
something
we
need
to
figure
out
where
to
put
it
first
and
I
would
love
to
hear
your
inputs
is,
is
mainly
session
segmentation,
so
in
the
puc
that
we
did.
C
B
Which
is
possible
but
I
think
it's
a
classic
POC
way
to
do
it
and
I
think
it
would
need
a
lot
of
CPU
power
than
in
actual
production
instances
to
actually
build
something
very
weird
over
the
head
and
around
five
corners
to
figure
out
what
a
session
is
and
I
think
that
is
something
we
definitely
should
do
in
a
level
earlier
like
in
the
tracking
or
even
in
the
data
transformation
that
we
also
have
couple
of
options
in
Jitsu
itself,
so
I
would
love
to
hear
everyone's
input
and
especially
Avon
working
on
the
product
intelligence
parts
of.
B
C
Sujitsu's
got
that
Anonymous
session
ID,
which
I
I
don't
know
if
we
verified
yet
whether
that
it
seems
based
on
my
testing,
but
at
least
for
that
given
session
it
can
change
per
it,
can
change
for
the
same
user
ID,
but
at
least
for,
like
the
duration
of
that
session,
it
stays
the
same
similar
to
I.
Think
how
snowplow
does
it
with
like
I
think
it's
called
like
the
anonymous
session.
C
Id
is
that,
were
you
looking
for
like
how
we
can
actually
attribute
it
to
like
a
specific
user
or
like
how
far
would
we
go
with
like
session
segmentation.
B
So
what
I
would
love
to
have
is
that
we
have
a
rule
that
we
can
set
up
in
reality,
what
a
session
means.
So
this
means
basically
everything
that
you
did
from
a
starting
point.
The
first
time
you
hit
a
UL
or
an
action,
because
we
could
also
Track
mobile,
apps
and
reality,
but,
let's
say
a
UL,
the
first
time
where
the
session
starts
and
then
up
to
a
certain
point
until
you
have
reached
a
certain
amount
of
inactivity.
B
B
I
still
can't
do
meetings
yet
coming
back
from
PTO
and
then
come
back
in
the
afternoon
to
the
application.
Would
this
be
a
new
session?
I
would
say
yes,
so
that
we
basically
can
easier
group
activities
with
each
other
and
have
a
better
understanding.
What
a
workflow
of
one
thing
at
the
time
is,
and
if,
as
far
as
I
have
seen
but
I
think
someone
should
Deep
dive
into
that
with
Jitsu.
B
Is
that
if
you
have
a
customer,
then
this
gets
immediately
picked
up
again
even
on
another
day
again,
and
it's
basically
connected
again
to
this
user
Anonymous
ID,
which
is
simply
created
once
but
I
think
it
would
be.
The
best
part
would
be
really
to
have
a
definition
that
we
can
even
go
up
to
to
the
to
the
product
that
a
project
can
say.
C
Yeah
I
think
there's
going
to
be
a
good
Deep
dive
that
needs
to
happen
with
Jitsu,
because
one
there's
there's
a
lot
of
different
parts
there
where
it's
like.
Okay,
we
we
have
that
Anonymous
user
ID,
but
that's
our
session
ID,
but
it's
not
pers
like
I,
think
it's
more
in
line
of
how
you'd
find
it
in
terms
of
like
it's
a
session
that
happens
like
in
the
morning.
C
C
If
we
can
change
the
interval,
that
of
how
it
like
resets,
that
I
don't
know
if
that's
just
purely
cookie,
based
or
not
so
yeah
I
think
a
deep
tie
for
predictive
will
have
to
be
done
for
the
for
us
to
understand
the
capabilities
it
offers
and
the
customizability
and
how
that
matches
up
with
how
we
Define
how
we
would
want
to
define
a
session.
D
E
Calls
this
sessions
in
tracking
snowplow
calls
it
sessions,
Jitsu
calls
it
sessions
and
they
usually
have
a
configuration
for
how
long
that
threshold
is
before
they
stop,
counting
it
as
part
of
the
current
session
and
generate
a
new
session
ID.
D
E
E
Least,
with
my
experience
I
don't
know,
maybe
someone
else
has
has
thoughts
about
that.
D
F
F
I
think
that
there
may
be
great
opportunity
here
to
also
include
very
privacy,
friendly
approach,
I,
absolutely
loved,
how
GitHub
experiment
defined
the
migration
keys
or
expert
migration
Keys,
which
were
independent
from
any
attribute
because,
like
right
now
how
we
provided
privacy
is
by
pseudonym
pseudo
anonymization
of
user
IDs,
which
is
not
perfect,
because
it's
based
on
some
constant
data,
plus
some
Secrets,
which
can
be
leaked,
can
be
without
enough
computing
power.
Cracked
Etc.
F
But
if
we
Define,
or
at
least
I
Envision,
that
if
we
use
similar
approach
as
was
used
by
the
GitHub
experiment,
when
you
just
change
the
random
generated
IDs
that
were
assigned
to
the
sessions
and
keep
track
of
them,
pointing
to
the
previous
one,
we
still
can
get
the
user
level
tracking,
but
with
the
very
privacy
friendly
way.
Because
this
wouldn't
be
this
identifier,
wouldn't
be
tied
to
any
in
any
form
to
the
Natural
person
rather
than
just
being
assigned
to
it.
F
E
C
There's
any
questions
so
Tim
I
think
we're
generally
interested
in
it.
Is
that
kind
of
give
you
enough
for
us
to
like
Define
and
start
pursuing
in
terms
of
like
conducting
these
deep
dives
into
how
they
can
put
this
further
Upstream
so,
like
I,
think
I
think
we're
generally
in
agreement
that
it
should
happen
earlier
rather
than
later.
So,
if
we
can
get
into
Jitsu,
like
is,
does
that
satisfy
your
point?
I
guess
is
what
I'm
asking.
B
Absolutely,
and
with
Jeremy
and
I,
think
we
have
the
right
person
there
on
the
team
to
work
also
with
everyone
from
product
intelligence,
open
an
issue
put
out
the
proposal,
and
then
we
get
everyone's
input
to
yeah.
I.
B
Think
that
that
also
was
one
of
the
discussions
that
we
had
so
far
in
the
slack
channel
was
really
about
how
we
are
going
to
do
tracking
around
schemas
Etc,
and
this
is
now
the
time
to
Define
all
those
points
of
what
can
we
do
reuse
as
many
things
that
industry
has
provided
us
and
is
doing,
but
also
see,
okay,
what
can
rethink
a
little
bit
or
that
we
have
re-implemented
through
halfways
to
basically
learn
snowplow
and
sessions
are
one
of
those
topics
so
yeah.
Absolutely
thanks
a
lot.
Everyone.
C
Nice
too,
yeah
there's
also
this
feature.
They
have
called
retroactive
user
resignation
which
I
I,
don't
I
can
I
believe
that
I
do
not
fully
understand
so
I
wonder
if
that's
something
we
could
potentially
leverage
as
well,
but
yeah
that'll
all
come
with
the
Deep
dive
cool.
So
I
just
have
a
couple
points
so
one
with
the
setting
up
analytics
on
gitlab.com.
C
There
was
already
a
slack
there
that
Sam
had
opened
up
about
this,
but
obviously,
given
the
recent
news
regarding
our
work
with
the
few
uses,
tiering
inactive
project
deletion-
I,
imagine
we'll
want
to
just
make
sure
we
handle
with
great
care
on
how
we
approach
the
announcement
and
Gathering
of
feedback
for
when
we
inevitably
moved
towards
setting
up
analytics
on
gitlab.org,
even
without
the
intention
of
opening
it
up
wider
than
that
organization.
C
It
still
has,
as
we
discussed
last
week,
people
who
aren't
team
members
are
part
of
the
company,
so
we'll
we'll
still
want
to
I
think
that
process
will
take
quite
a
while,
but
to
say,
I'm
open
to
slack
thread
earlier
this
morning
on
whether
or
not
it
makes
sense
to
maybe
start
with
the
internal
handbook,
which
I
think
will
be
a
good
step
towards
how
we
announce
it
for.com.
So
that
might
be
a
good
iteration
towards
that,
but
I'm
curious.
If
anyone
has
any
other
any
other
thoughts
on
that.
A
C
Yeah,
the
dev
Kit's,
getting
really
close
to
being.
You
know
well
for
development
purposes,
kubernetes
ready,
there's
a
lot
more
work.
C
That
has
said
it
happened
with
to
get
it
to
production,
but
thankfully
there's
a
lot
of
work
that
observability
and
Ops
Trace
has
been
doing
with
their
click
house
Operator,
just
to
basically
scale
out
click
clusters
at
the
same
time,
I've
as
just
to
kind
of
what's
what
my
current
focus
is:
I've,
been
diving
deep
into
how
resource
management
and
like
destination
management
works
for
Jitsu
and
how
that
could
potentially
be
orchestrated
at
the
same
time.
C
C
So
it
does
seem
supportive
of
having
kind
of
like
a
shared
data
pool,
but
then
scoping
it
such
that
once
you
actually
access
Cube
you,
you
only
see
the
data
you're
supposed
to
so
that's
part
of
what
I've
been
looking
at
and
how
that
ties
into
a
production
deployment
and
how
that
can
be
managed,
but
yeah.
That's
pretty
much.
What
I'm!
Looking
at
Jeremy!
You
have
the
next
point.
E
Yeah
so
been
kind
of
thinking
about
how
we
want
to
try
and
model
the
event
data
that
we
that
we
collect
and
like
how
how
we
present
that
kind
of
thing.
So,
when
I'm
looking
at
a
project,
do
I
do
I
see,
can
I
see
the
analytics
sort
of
from
that?
Is
it
related
to
that
project?
Is
it
related
to
a
namespace
or
group?
E
B
As
I'm
always
much
faster
speaking
than
typing,
I
will
try
to
talk
it
out
at
the
only
thing
that
we
decided
a
couple
of
weeks
ago
was
the
Kenny
and
I
that
we
simply
will
base
this
on
namespace
group
level
so
that
you
have
analytics,
but
I
think
it
would
be
really
good
to
also
have
some
sort
of
connection
of
one
property,
maybe
in
a
project.
The
question
is
also,
do
you
do
you?
B
Think
I
think
it
would
be
good
to
connect
to
one
of
those
instances
on
a
on
a
namespace
level,
so
that
you
can
also
what
we
will
need
is
most
probably
DNS
and
custom
domains
and
stuff
like
that,
so
that
we
don't
have
too
much
hassle
with
domains
Etc
most
probably,
and
then
they
can
create,
like
properties,
I
think
they
are
also
according
to
Google
analytics
and
things
like
that.
To
start
okay,
I'm
tracking
something
against
this.
But
this
is
something
classic
topic
for
product
management.
E
I
was
wondering
if,
like
using
environments
like
sets
of
property,
that
is
common
in
tracking,
so
maybe
you
specify
the
environment.
As
you
know,
staging
you
know:
marketing
and
production,
marketing
and
production
application
staging
application,
but
do
we
want
to
try
and
build
in
tooling
that
makes
that,
like
understandable
to
people
or
something
I,
don't
know
just
kind
of
thinking
about
that.
D
So
I'll
I'll
give
my
opinion
here
and
feel
free
to
challenge
this,
because
I
wasn't
in
some
of
those
discussions
with
Kenny
previously.
D
D
The
way
that
I
would
think
that
we
could
do
this
is
we
have
one
instance
of
the
tracking
cluster
or
a
way
to
segment
that
tracking
cluster
into
Timmy?
Your
example
of
you
know
the
mobile
app
a
web
app
and
a
desktop
application
and
having
some
sort
of
attribute
in
the
tracking
cluster
be
the
way
we
could
differentiate
between
those
different
applications
and
then
on
a
per
application
basis.
D
That's
where
the
experience
around
visualizations
consuming
the
data
and
getting
insights
from
it
would
come
now,
whether
that
sits
at
the
root
level
group
of
a
namespace,
a
subgroup
or
an
individual
project,
I'm,
not
so
sure.
What
the
right
answer
to
that
question
is
but
I
think
if
we
do
the
the
bifurcation
of
what
all
that
looks
like
on
the
whatever
that
property
is
in
the
the
tracking
stack
is,
then
it
just
becomes
a
matter
of
well.
Where
do
we
put
this
in
our
git
lab
hierarchy
of
access
to
it?
D
Whether
we
put
it
yeah
by
the
last
part,
whether
we
put
it
at
the
the
projects
level,
the
subgroup
level
or
only
at
a
root
group
level,
I
think
that
decision
can
probably
come
later,
I
think
in
terms
of
the
data,
if
it
has
some
sort
of
attribute
that
ties
it
to
either
a
specific
tracking
cluster
of
that
JCC
stack
or
there's
something
in
all
of
the
data
in
that
tracking
cluster.
That
says
this
is
for
a
mobile
app.
This
is
for
the
second
mobile
app.
Then
we
can
figure
out
where
it
lives
in
gitlab.
D
E
I
I
guess
let
me
rephrase
my
question
because
I'm
thinking
about
this
visually
so
that
then
I
can
figure
out
how
we
want
to
try
and
model
this
from
an
engineering
perspective
when
I
as
someone
who
is
like,
let's
say
because
I
come
from
the
growth
team,
I
can
think
of
the
PM's
perspective
from
the
growth
team
fairly
easily.
So
if.
F
E
The
growth
team
and
I'm
tracking
some
information
that
I'm
trying
to
figure
out
if
I,
want
to
like
roll
out
this
feature
or
spend
more
time
on
it
or
not.
I'm
like
where
do
I
want
to
see
that
information
would
I
go
to
the
gitlab
org
top
level.
Namespace
do
I
want
to
see
all
of
the
metrics
that
people
have
defined
and
trying.
E
You
know
like
try
and
find
my
specific
view
of
that
data
in
some
very
large
bucket
of
of
analytics
presentations
like
that's
called
widgets
views
whatever
and
or
do
I
want
to
go
to
like
a
sub-project
that
I've
created.
That's
maybe
about
this
specific
thing
or
do
I
want
to
you
know
like
can
I
create.
You
know
how
we
have
like
issues
that
are
like
not
part
of
the
git
lab
project.
E
I
can
create
a
separate
group
and
have
issues
in
in
like
that
thing
and
have
discussions
in
that
like
how
do
we
want
to
model
it,
because
it's
important
for
how
we
store
the
information
about
how
we
want
to
present
the
data?
How
we
want
to?
Does
that
make
sense?
It's
like
the
tracking
events.
Like
will
all
go
into
the
one
system
but
like
how
do
we
want
to
allow
it
to
be
viewed?
E
Do
we
think
it's
more
confusing
to
have
it
at
multiple
layers,
because
I
may
struggle
to
find
something
that
someone
else
has
set
up
or
do
we
want
to
have
it
like,
or
do
we
think
it's
more
confusing
that
it's
like
one
bucket
like
one
place
where
I
go
to
try
and
find
everything?
E
D
In
some
useful
way,
and
so
then,
when
I
think
about
modeling
that
I'm
like
how
do
we
want
to
present
it
yeah
that
makes
sense,
I
mean
I,
I,
think
at
the
smallest
unit
you
could
put
it.
We
could
put
it
at
the
project
level.
Have
that
be
specific
to
one
application,
then
the
question
becomes:
what
does
the
aggregate
of
all
multiple
projects?
What
does
that
experience?
D
Look
like
I
think
doing
that
at
the
group
would
make
sense
in
that
case,
but
that
could
also
be
confusing
if
organizations
have,
because
we've
seen
this
with
a
lot
of
our
customers
in
in
other
categories,
where
they'll
have
like
a
division
that
has
a
project
under
one
division's
root
group
and
then
another
division
with
a
project
under
another
root
group,
and
then
how
do
we
combine
those
two,
probably
the
aggregation
of
all
that
probably
a
harder
use
case
than
the
single
we
just
put
it
in
the
project.
D
You
get
Project
Specific
information
at
that
point,
so
I
don't
know.
If
that's,
the
answer
to
your
question
sounds
like
we
probably
could
do
some
more
research
in
this
area
to
figure
out
what
pros
and
cons
of
different
approaches
are.
C
Yeah,
it's
gonna
really
depend
on
who
you
ask
because,
like
depending
on,
if
someone's
okay
yeah,
it
just
depends
on
the
hierarchy
of
your
organization.
But
then
it's
also,
then
you
can
also
say
it
depends
on
how
the
organization
sets
it
up.
But,
like
you
know,
perhaps
you
have
someone
who's
like
more
management
position
that
wants
to
see
all
the
different
like
dashboards
at
a
higher
level
without
having
to
jump
into
each
individual
project.
C
So
they
don't
want
to
have
to
go
at
the
higher
level
to
you
know,
dig
through
a
number
of
dashboards
to
find
the
one
that
they're
interested
in
so
I
think
ultimately,
you'd
want
it
accessible
in
all
levels,
but
then
just
have
it
scoped
down,
but
then
that
gets
more
complicated
based
on
our
permission
model
and
that
that's
a
whole
separate
topic
of
like
who's,
even
going
to
be
able
to
see
these
and
then,
like
then
segments
in
col
who
can
see
it
at
which
level
so
I
don't
really
know
where
I
was
going
with
that
other
than
it's
a
really
complicated
problem.
C
D
About
it
so
yeah
well,
what
would
it
make
sense
if
we
did
something
that
you
get
all
the
data
at
your
root
group
at
your
namespace
level
and
then
just
provide
controls
to
segment
it
down
to
just
the
mobile
app
the
web
app
desktop
app
at
that
point,
rather
than
spread
it
across
multiple
projects.
E
That's
essentially
what
I'm
talking
about
like,
like
the
the
data
will
be
available
at,
like
you
can
just
say
like.
Oh
everything
in
this
project
is
querying
some
you
know
like
for
this
environment
or
this
application
name
or
whatever
we
you
know.
However,
we
decide
to
do
that,
but
it's
it's
like
I'm
thinking
about
it
from
the
interface
perspective
of
like
maybe
I,
have
like
complex
dashboards
in
projects
and
I
only
have
Discovery,
so
that
I
can
find
the
information
for
that
I.
E
Don't
show
all
of
the
dashboards
at
like
the
group
level
for
that
project
and
the
top
level
group
I
like
have
a
different
type
of
way
of
just
discovering.
What's
where
the
data
will
be
presented
to
me
for
for
specific
things,
I,
don't
I,
don't
know
if
that's
another
way
of
trying
to
say
it,
but.
C
E
I'm
not
proposing
anything
I'm
trying
to
get
like
the
thought
around
like
so
that,
then,
when
requirements
come
in
for
like,
let's
make
sure
that
we
can,
you
know
Version
Control,
the
these
widgets,
these
dashboards
or
something
it's
like
well,
how
do
we
want
to
model
them
so
I'm
just
trying
to
get
people
to
think
about
that.
B
Really
good
point
and
I
get
it
now
that
it's,
it
might
be
that
we
have,
let's
call
it
the
mobile
app
or
it's
called
the
website,
because
it's
easier,
it's
our
main
use
case,
and
you
have
simply
one
team
that
is
responsible
for
the
checkout
and
they
want
to
see
mainly
in
the
in
their
project,
what
happened
or
everything
that
happened
to
the
checkout
and
have
specific
dashboards
that
are
just
specific
to
their
experiments
and
so
on.
Right.
E
Yes,
and
because
I
actually
see
you
know
how
we
can
link
to
Mrs
and
even
feature
Flags
like
comments
like
I
would
imagine
that
people
would
want
the
same
tooling
for
for
analytics.
I'd
want
to
be
able
to
link
to
dashboards
I
want
to,
and
you
know
like
when
we
think
of
the
vast
amount
of
data
and
how
we
can
present
it
in
different
ways.
The
the
challenge
becomes
managing
how
you
interact
with
with
all
of
that
stuff.
So,
where?
How
do
we
want
to
structure
that
like?
Can
we
link
to
them?
E
Can
I
link
to
specific
views
in
my
dashboard.
B
But
I
think
that
one
topic
that
comes
to
my
mind
is
rather
to
to
link
one
to
one
so
that
basically
a
project
contains
everything
that,
but
that
that,
if
we
build
up
a
good
meta
system
like
grafana
has,
for
example,
where
you
have
simply
tags
and
labels
and
stuff
like
a
good
descriptions
per
dashboard,
because
the
biggest
fear
is
what
I've
seen
in
just
look
at
our
assassins.
B
Yeah
duplicates
with
exactly
three
percent
difference,
yeah
and
I.
Think
one
of
the
things
that
I'm
missing,
for
example,
for
if
I'm
looking
at
size
sense
and
if
you
then
segment
basically
dashboard
a
and
dashboard
B.
Is
that
a
lot
of
topics
like
tags,
not
not
tags?
They
are
called
so,
maybe
basically
can
say
in
a
graph.
Okay.
By
the
way
we
have
released
feature
a
expectations.
C
B
Annotations,
thank
you
annotations
to
a
certain
point
is
that
you
have
them
exactly
on
one
graph
and
One,
dashboard
and
and
I
think
that
in
then
I'm
looking
over
to
another
thing
and
I'm
like
I'm
missing
the
whole
thing,
so
I
think
that
that
if
we
are
able
to
solve
those
things
that
we
have
reusable
components
also
to
some
extent
so
that
you
have
can
have
views
versus
dashboards
and
we
are
not
reiterating
every
time
and
then
have
15
different,
outdated
dashboards.
I
think
then
we
we
would
also
be
ahead
a
lot
of
other
areas.
B
E
A
C
Well,
definitely
I
mean
as
far
as
next
steps
and
we're
also
approaching
time
generally.
Would
you
be
willing
to
open
up
like
an
issue
or
an
epic,
where
we
can
carry
this
conversation
async
and
continue
to
kind
of
determine
what
kind
of
Discovery
needs
to
happen
for
us
to
continue
to
narrow
this
down.
C
E
C
Awesome,
thank
you.
Anyone
have
anything
else
they
would
like
to
bring
up
before
we
call
the
meeting.