►
From YouTube: 2022-11-15 Product Analytics Sync
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
I'll,
intro,
hello,
everyone
welcome
to
the
product
analytics
weekly
I'll,
kick
us
off
by
sharing
my
screen
and
walking
through
the
billboard.
Can
everyone
see
yep
yep
well
see
what
I'm
sharing?
A
Well,
let's
walk
through
the
board.
First
up
in
workflow
design,
we
have
rope
your
interest,
instrumentation
screens,
onboarding
flow.
This
is
still
ongoing,
but
anything
you
would
like
to
add
to
this.
B
Yeah
we're
just
coming
back
from
being
away
for
a
few
days
we
were
discussing
the
back
end
related
aspects
of
making.
This
all
tick,
I
need
to
get
back
into
those
conversations
and
see
where
they're
at
and
then
go
on
from
there.
But
the
designs
are
basically
nearly
all
they're,
all
nearly
all
signed
off
and
they're.
Most
of
them
have
been
waited
and
have
an
implementation
plan
ready
to
start
getting
scheduled.
A
Awesome
then,
we
also
have
iron
boarding
and
Jutsu
Q2
project
graphql
type,
I
believe
this
is
also
one
of
your
issues.
B
Yep,
which
is
probably
going
to
be
adjusted
or
changed
or
adapted
based
upon
the
back
end,
conversation
we're
having,
but
essentially
we're
going
to
need
some
way
of
being
able
to
get
that
Jitsu
key
to
the
front
end
to
be
rendered.
B
C
A
Awesome
then,
we
also
have
a
blocked
issue
for
track
usage
on
the
internal
handbook.
I
believe
this
is
blocked
by
infrastructure.
D
Yeah,
so
if
you
want
to
just
jump
quickly
to
review
in
review
and
on
my
issue,
I've
published
the
initial
draft
and
I
published
I've
put
I've
posted
the
initial
draft
for
the
production.
Writing
this
review
for
infrastructure
and
security
to
review.
D
That's
yeah
linked
somewhere
yeah
there.
It
is
it's
touching
on
four
thousand
words.
So
if
you
want
to
read
it,
please
by
all
means,
I'd
appreciate
your
feedback
or
any
corrections
to
the
information
there,
but
I
think
it's
a
good
first
iteration
for
us
to
at
least
get
the
instrumentation
on
the
internal
handbook
going.
Given
that
it's
a
internal
only
feature
you
know
Endeavor,
so
I'm
I've
already
pinged
in
the
necessary
parties
to
review
and
give
feedback
on
that
or
if
they
need
other
people
to
review
for
them.
A
Cool
thanks
for
that
update,
yeah
400
lines,
you
weren't
you
weren't
lying.
A
The
next
ready
for
development
issue
is
side
to
axle,
but
I
believe
this
is
actually
in
development,
because
I
think
this
is
going
to
be
solved
by
Max.
You
have
a
documentation
anymore
right.
E
I
do
and
Lorena
has
just
reviewed
the
actual
documentation
bits
of
it
and
that
will
include
sort
of
like
a
small
introduction
to
the
products
analytics
work
which
I
intend
on
being
sort
of
bogged
out
considerably.
But
the
main
purpose
of
that
Mr
is
to
add
the
initial
dashboard
and
visualization
schemas
to
the
code
base
and
link
to
them.
So
folks
know
where
they
are.
B
Yeah,
so
that
that
axle's
work
should
be
adding
that
link
to
the
admin
settings
and
also
updating
that
documentation.
That
Max
has
been
working
on
to
include
details
about
what's
in
the
admin
settings
which
so
that
should
probably
go
back
to
ready
for
development
or
in
development.
On
the
two
I.
Don't
know
where
axle
is
on
that
yeah.
A
A
The
next
in
development,
one
first
in
the
queue
is
mine.
That's
Cube,
rendering
a
line
chart
with
Cube.
This
is
something
that
I've
been
busy
with
today.
Hopefully
now
that
my
other
issue
that
I
have
here
is
the
separation
of
dashboards
and
widgets
into
separate
files
is
in
review
with
Axel
I
can
get
my
Branch
ready
to
be
merged,
because
this
this
this
issue
is
based
off
this
issue,
if
that
makes
sense,
because
we're
building
new
infrastructure
I'm
using
this
change.
On
that
sorry,
my
brain
works
hard.
E
Kind
of
what
we
just
talked
about
so
yeah
I
think
we're
agreed
on
it
at
this
point.
So
I
think
we
can
close
that
once
the
Mr
that
adds
the
schema
to
the
documentation
has
been
merged.
E
I'm,
not
expecting
it
to
be
sort
of
a
final
version
one,
but
while
we're
in
Alpha
we
can
break
things
as
we
see
fit
without
having
to
worry
about
version
numbers,
but
it
would
be
good
to
get
something
merged.
So
at
least
we
can
iterate
from
that
point
and
we
can
make
assumptions
based
on
the
current
state
of
the
schema,
which
is
kind
of
what
I'm
doing
already
so
I'm
hoping
once
I've
addressed
all
the
comments
from
Lorena
and
anyone
else
who
wants
to
input
on
it.
A
So
next
up
in
review,
we
have
one
from
Axel,
which
is
adding
a
loading
State
I
reviewed
this
I
think
Rob
as
well.
I'm,
not
aware
of
any
other
updates
on
this
quickly.
Just
gonna
check.
A
B
E
B
E
E
D
E
So
this
is
like
half
done
now,
so
there
were
two
Mrs.
The
first
one
is
now
merging
in
production
behind
feature
plaques,
obviously,
where
you
can
use
graphql
to
pull
out
basic
information
about
a
dashboard,
namely
just
the
name
description,
I,
think
a
list
of
widgets,
the
second
Mr.
That's
just
wanted
to
maintain
a
review.
E
Thank
you
young,
for
looking
at
that
adds
the
rest
of
the
information
about
the
dashboard,
so
you'll
be
able
to
use
graphql
to
query
dashboards,
widgets,
visualizations
and
all
of
the
data
within
or
a
subset
of
that
information.
Depending
on
how
much
you
want
pretty
happy
with,
it
seems
to
work
pretty
well,
so
hopefully
the
maintainer
won't
hold
it
up
too
much
so
that
should
be
merged
this
week
and
we
can
close
that
issue
off.
A
Awesome
and
yeah
we've
already
talked
about
this
one
and
I've
also
covered
this
in
verification.
I
see,
Axel
has
move
Cube,
API
proxy
feature
to
EE
I'm,
not
sure
if
anyone
has
any
updates
on
that.
E
A
B
Yeah,
that
is,
reverting
the
QPR
qgis
implementation,
our
proxy
back
to
post,
although
Tim
has
messaged
earlier
today
regarding
some
issues
he's
having
with
that
with
his
work
that
he's
doing
to
do
with
query,
building
for
a
UI,
so
I'm
currently
reviewing
and
looking
at
that
to
try
and
figure
out
what's
going
on.
If
it's
an
issue
with
post
or
if
it's
just
you
know
what
what's
happening
so
to
be
continued.
A
Yeah
I
should
then
does
anyone
know
about
Axel's,
MR2
or
issue
to
move
Cube
API
proxy?
Oh
no.
This
is.
D
F
Yeah,
so
I
just
wanted
to
spend
a
few
minutes
after
our
conversations
last
week,
it
looks
like
we
have
some
confusion
around
our
since
we're
using
the
term
MVC
internal
preview
release
customer
release
in
a
few
different
places,
so
I
wanted
to
just
make
sure
we're
all
on
the
same
page
in
terms
of
where
we're
trying
to
go
to
what
are
some
of
those
milestones
and
what
are
we
doing
to
break
those
Milestones
down
and
as
part
of
that,
the
first
way
I'd
like
us
to
think
about
this
is
we're
doing
two
major
efforts
to
culminate
in
two
different
releases.
F
F
After
that,
the
next
big
milestone
release
is
going
to
be
our
first
customer
facing
release.
That's
where
we're
actually
going
to
be
going
to
external
users
and
saying
hey,
you
have
a
gitlab
free
premium,
ultimate
whatever
subscription.
We
would
like
you
to
use
this
in
your
real
world
applications,
notably
each
of
those
types
of
release
have
a
different
epic
associated
with
them.
I've
linked
them
both
in
the
document.
F
The
customer
facing
one
I
think
we're
well
away
from
so
the
requirements
are
still
in
in
flux
there,
but
the
internal
preview,
one
I,
feel
pretty
good
about
what
our
scope
of
requirements
is
for
this.
So
I'd
like
to
briefly
review
that,
and
then
we
can
talk
about
how
that
gets
broken
down
into
what
we're
calling
various
mvcs
and
iteration
plans,
and
this
is
linked
in
the
document
if
you
want
to
follow
along
at
home
as
well,
but
really
the
requirements
for
the
internal
preview.
F
Are
these
four
here
one
we're
going
to
need
a
repository
that
has
our
development
environment
so
that
we
can
actually
build
and
work
on
this
project
two?
We
need
to
deploy
this
to
a
production,
quality
environment
and
add
that
instrumentation
to
the
internal
handbook,
that's
how
we're
going
to
be
actually
doing
the
dog
food
and
so
that
we
have
a
real
world
application.
That's
not
gitlab.com
to
get
around
some
of
the
data
issues.
We
talked
about
a
few
months
ago.
F
Thirdly,
and
this
is
the
the
one
I
think
where
we
have
some
confusion
around
is
we
need
to
be
able
to
provide
pre-configured
dashboards
of
some
sort
out
of
the
box,
and
the
reason
for
this
is
that
we
want
custom.
We
want
users
who
are
going
to
be
internal
git,
lab
users,
but
ultimately
will
be
customers
one
day
to
be
able
to
very
quickly
go
from
I
clicked
the
button
to
turn
it
on
to
I'm
immediately
getting
some
sort
of
insight
result
I'm
getting
some
sort
of
value
out
of
product
analytics
quickly.
F
F
So
people
know
how
it's
going
to
affect
them,
and
what
we're
doing
on
this
piece
about
hard-coded
dashboards
and
hard
code,
visualizations
I
realize
this
is
a
little
bit
confusing
since
we're
also
working
on
customizable,
dashboards
and
widgets.
In
parallel,
when
we
originally
set
up
these
requirements,
we
thought
it
was
going
to
be
more
complicated
to
actually
do
the
customizable
schema
driven
dashboards,
which
is
why
we
de-scoped
down
to
just
this
hard-coded
set
of
dashboards.
It
turned
out.
F
It
was
actually
easier
to
just
do
the
customizable
dashboards
rather
than
hard
coding,
which
is
why
we
went
forward
with
that.
That
said,
those
customizable
dashboards,
that's
really
something
that's
going
to
be
blocking
for
what
we
ship
to
external
customers
for
when
we
want
them
to
work.
But
this
need
for
something
pre-configured
for
the
internal
preview
is
still
there
because
customizability
is
addressing
a
pain.
Point
around
I
need
to
be
able
to
see
what
matters
to
me,
whereas
the
fact
that
we
have
dashboards
that
are
pre-configured
and
hard-coded
addresses
the
pain
Point
around.
F
It
takes
me
a
long
time
to
get
started
before
I
get
value.
So
those
are
similar
points
but
they're
slightly
different
pain
points
that
they're
addressing
so
I
talked
a
lot.
I
would
encourage
you
also
to
review
the
child
epics
under
here.
We
can
make
iteration
plans
that
bubble
up
to
get
us
to
where
these
end
requirements
ultimately
are
for
the
internal
preview,
but
I
wanted
to
know.
Did
that
help
clarify
things?
B
So,
first
of
all,
thank
you
for
explaining
that
I
would
say
that
the
list
of
issues
that
we
have
under
the
epics
I
often
find
really
hard
to
follow,
especially
because
they
were
a
lot
of
them
were
created
way
before
we'd
even
start
like
before,
I
joined
the
team
and
then
half
the
team
had
joined
the
team
essentially,
and
a
lot
of
them
are
now
out
to
date
or
on
up
or
aren't
following
what
we
were,
what
we've
sort
of
what
we've
just
discussed
around
how
we
started
moving
ahead
faster
with
the
customizable
stuff
that
we
actually
planned.
B
So
there's
a
lot
of
issues
in
there
which
just
don't,
align
or
make
any
sense
to
me
so
I,
more
or
less
ignore
them
and
just
go
with
what
I'm
being
told
by
Dennis
or
you
Sam,
on
a
weekly
basis
on
what
I
should
be
focusing
on.
B
So
there
might
I
I'd
love
to
see
those
sort
of
combed
through
and
just
made
sure
they
are,
after
that
they
probably
are
now
I.
Just
I've
just
got
an
assumption
in
my
head.
D
So
yeah
I
just
wanted
to
interrupt
it
quickly.
If
you
or
anyone
encountered
an
issue
where
you
don't
think
it's
a
line
or
out
of
date,
then
please
raise
it
in
the
issue.
That
way,
you
know
Sam
and
I
are
spending
sessions
to
go
through
everything
and
then
make
sure
everything's
up
to
date.
But
if
there's
something
specifically,
that
doesn't
make
sense
because
and
something
I
wanted
to
bring
up
in
the
red
show
as
well.
Is
that
I've
seen
Us
close
old
issues
because
we're
like?
D
Oh
that's,
really
out
of
date
and
we've
moved
on
past
that?
But
if
we're
supposed
to
be
keeping
issues
of
seeing
the
sources
of
Truth
and
we
end
up
actually
replacing
those
old
issues
with
new
ones,
then
we
should
actually
just
be
going
back
and
updating
those
or
again,
if
they
don't
make
sense
like
ask
Sam,
Tim
or
I.
You
know
what
we
mean
by
that
or
it's
like
you
know
severely
out
of
date,
because
it's
you
know,
building
blocks
for
dashboards
and
that
doesn't
really
mean
a
whole
lot.
D
Then
we
can
go
in
and
clarify
that,
but
that's
just
a
really
long
way
of
saying
like
if
there's
something
that
confuses
you
or
this
issue
or
if
the
Epic
itself
doesn't
make
sense,
and
that
means
that
Sam
and
I
are
or
anyone
else
can
help
to
kind
of
rate
and
make
sure
it
makes
more
of
a
cohesive
sense.
Yeah.
E
We
will
need
to
based
on
that
schema
that
we've
got
now
make
it
possible
that
folks
can
create
our
predefined
dashboards
automatically
that
the
ux
flow,
for
that
might
be
something
on
the
lines
of
a
an
MR
that
we
can
create
for
a
project
automatically.
That
allows
them
to
add
that
dashboard
or
we
can
add
stuff
in
it
to
just
hard
code
it
and
not
have
to
worry
about
the
code
end
of
it
at
all
I'm
open
to
how
we
do
that.
But
I
don't
think
we
have
an
answer
to
that.
Yet.
F
B
F
That
piece
I
think
that's
one
of
the
things
we
can
dig
into
as
part
of
the
the
ux
weekly
meeting
that
we'll
have
for
for
what
that
looks
like.
We
definitely
don't
need
to
hold
back
any
of
the
work
that
we're
doing
in
terms
of
customizable
dashboard,
especially
because
this
is
internal.
We
can
iterate
very
quickly
here
with
a
really
low
level
of
shame,
because
we're
not
asking
anyone
to
pay
us
money
for
this.
F
This
is
something
that
we
are
going
to
be
using
ourselves
only,
and
so
that
comes
with
a
lot
more
opportunity
to
iterate,
maybe
more
quickly
than
we
would
for
external
things.
I.
E
Think
that's
that
I
think
as
well.
I
think
I
can
see
an
accidental
customer
setting
up
the
stack
and
then
being
presented
with.
You
know
a
bunch
of
options.
You
know
what
is
this
application
for
if
it's
e-commerce
right?
Well,
then
it
has
a
bunch
of
dashboard,
we'll
create
you
an
MR
with
a
bunch
of
dashboards.
That's
probably
a
step
too
file
than
what
we
need
now.
Oh
look.
Dennis
has
a
big
me
too
yeah
suggestion.
D
D
So
I
mean,
if
we're
thinking
internal
preview,
we
don't
need
to
worry
about
the
fancy
like
onboarding
flow,
which
is
important
when
we
get
to
external,
but
for
the
purposes
of
internal
handbook.
For
example,
we
know
what
the
dashboard
is
going
to
look
like.
We
have
access
to
the
repo
we're
already
going
to
make
a
merge
request
to
instrument.
It
just
add
another
one
to
add
that
dot,
gitlab
files
for
all
the
schemas,
so
that
we
have
people
dashboards
to
start.
E
C
But
I
mean
from
an
engineering
strategic
standpoint
how
I
see
this
to
some
extent,
you
move
forward
with
building
these
dashboard
schemers
the
dashboard
formats
building
one
after
the
other
visualization
for
it,
so
that
we
have
different
types
of
charts
and,
to
some
extent
same
Dennis
and
I
are
simply
going
to
build
DML
files
with
One
dashboard
after
the
other
and
building
those.
That's.
C
Why
I'm
also
looking
currently
into
the
query
Builder,
to
give
us
already
the
opportunity
to
build
very
fast,
very
quickly,
some
queries
and
you
simply
keep
pushing
so
that
we
can
have
more
features
on
those
dashboards
and
what
they
will
simply
be.
The
ones
that
we
provide
beforehand
is
that
they
are
read-only
and
hopefully
that
at
the
later
point
and
the
point
quite
soon,
we
will
also
have
basically
yeah.
C
You
can
also
add
more
of
those,
because,
when
I
use,
postdoc
and
I'm
more
than
happy
to
set
up
a
demo
so
that
you
can
also
have
some
instance
how
they
solve
it
is
like
they
are.
D
C
You
can
build
dashboards
now
to
figure
out
from
which
country
the
people
are
coming
and
like.
Why
haven't
you
built
this?
For
me,
this
is.
This
was
done
in
the
90s
before
for
counting
pixels
and
I.
Think
that's
that's
a
little
bit
the
topic
here
and
we
maybe
simply
look
into
okay.
We
built
very
easy,
PowerPoint,
charts
and
say:
okay
check,
check,
check,
check.
Those
are
the
the
the
charts
that
we
want
to
build
and
have
on
the
page
and,
and
the
main
part
is
really
getting
the
steam
schema
ready,
having
visualizations
for
it.
F
And
as
a
starting
point
for
what
those
dashboards
will
look
like
I
would
encourage
you
also
to
look
at
the
screenshots.
We
took
from
the
proof
of
concept
around
both
the
audience
and
the
behavior
until
we
come
up
with
something
new
or
decide
to
change.
This
we'll
use
those
four
items
as
our
starting
point
of
where
we
want
to
get
to
unless
we
find
some
other
things
that
we
want
to
do
instead
for
those
dashboards,
but
let's
use
those
as
our.
This
is
where
we're
shooting
for
V1
right
now,.
D
And
I'll
create
issues
for
those,
because,
understandably
those
aren't
you
know
defined
as
separate
units
of
work
and
we're
included
just
as
screenshots
and
summed
up
as
a
we
should
provide
something
based
off
the
vision.
Proof
of
concept,
so
I'll
further
build
that
out
today.
So
we
can
all
review,
make
sure
that
that's
well
defined,
but
just
iterate
on
reiterate
on
Sam's
Point,
highly
recommend
checking
out
the
rest
of
the
Epic,
for
example,
like
customizability
we've
initially
talked
about
it.
D
Turning
into
this
like
whole,
like
editor
of
dashboard,
where
you
can
edit
the
queries
in
line
or
something
like
that,
at
least
for
now,
so
definitely
check
out
all
the
the
epics
inside
the
internal
preview
and
the
issues.
A
My
quick
to
sense
that
I
would
like
to
add
is
thanks.
Sam,
for
going
through
this
I
found
it
really
helpful
to
first
off
get
an
overview
of
you
know
what
we
want
to
do
in
a
Refresh
on
that,
and
also
an
acknowledgment
of
where
we
are
and
how
that
does,
and
potentially
you
know,
can
affect
our
steps
going
forward
and
also
it
helps
me
to
have
that
mental
split
between
or
created
fight
between,
our
very
first
MVC
and
the
MVC
after
that,
which
is
like
customer
facing,
and
also
like
that.
A
F
Yeah
glad
to
hear
it,
and
and
for
everyone
I
mean
if
you
ever
have
questions
about
this
type
of
stuff.
Please
ping
me,
because
if,
if
you're
curious
about
it,
probably
someone
else
in
the
group
is
as
well,
so
we
should
definitely
talk
about
it
to
make
sure
we're
on
the
same
page,
working
towards
the
same
goals.
B
Yeah
I
appreciate
that
I
definitely
have
got
very
confused
myself
regarding
where
we
are
in
terms
of
schemas
and
whether
we're
using
schemas
or
using
what
Tim
started
out
doing
with
putting
visualizations
into
our
repo
directly
and
how
that
was
going
to
mesh.
So
knowing
that
we,
the
general
that
we
can
just
hard
code,
a
bunch
of
yaml
files
into
the
internal
handbook
for
now
using
this
schema
that
we've
jumped
ahead
on
is
great
and
I.
B
Think
yeah,
on
top
of
that,
just
I
want
to
say,
is
just
to
really
congratulate
everyone
on
how
far
we've
actually
come.
Considering
we
didn't
all
the
things
like
customizable
schema
structure
and
how
long
that
we've,
you
know
when
I
first
joined
how
little
we
had.
B
We
had
a
proof
of
concept
that
was
definitely
nowhere
near
ready
for
production
use
in
any
way
and
how
far
we've
come
since
then
to
actually
have
a
fleshed
out
medium
to
long-term
solution
that
can
get
us
at
least
a
few
Milestones
down
the
line
before
we
have
to
start
deviating
or
making
any
more
complicated
than
it
all
really
is
it's
a
really
big
achievement
for
our
team?
I
think.
D
Cool
I
think
the
next
Point
I've
already
announced
this
on
slack,
so
I'll
just
cover
it
briefly,
since
we're
running
low
on
time
now,
the
user
script's
been
updated
and
now
I'll
auto
update
by
default,
if
you're
using
tampermonkey,
it
will
check
for
updates
once
a
day.
D
It's
now
pointed
to
the
new
cluster,
and
so
we've
already
been
receiving
data,
but
if
you
haven't
already,
you
do
need
to
manually
update
one
more
time
to
make
sure
that
you
have
the
download,
URL
or
update
URL
parameters
in
the
header.
That
way
it
will
check
for
updates
going
forward
other
than
that
yeah.
We
should
hopefully
not
have
any
more
cluster
migrations
to
have
to
do
at
least
temporarily,
and
you
know
in
the
next
Milestone
they're
looking
at
how
we
can
automate
getting
that
data
set
available.
D
So
people
always
have
a
fresh
set
of
data
to
work
with
we've
already
been
receiving
more
events.
So
it's
good
to
see
that
we've
restored
event
collection.
There.
D
I
will
provide
these
updates
later.
I
would
like
to
I
would
love
to
see
some
show
and
tell
so.
I
can
prepare
an
async
update
for
for
hiring
an
infrastructure.
A
Cool
I'll
quickly
share
my
screen
just
so
that
this
also
shows
up
on
the
recording.
Yeah
I
would
also
really
like
for
us
to
get
into
this
habit.
More
often
of
you
know,
sharing
our
victories
and,
like
Rob
said,
like
we've,
we've
came
a
long
way
and
even
in
the
short
time
that
I've
been
this
team,
it's
it's
very
cool
to
see
the
progress.
A
So
what
I
would
like
to
share
is
some
I've
done.
Is
I've
updated
our
dev
kit
readme
with
updated
instructions
when
I
joined
it
was
bit
stale
and
also
wasn't
like
up
to
like
the
latest
changes.
So
please
have
a
read
through
and
I'm
sure
I
made
a
mistake
here
or
there
I
try
to
replicate
this
as
much
as
possible,
but
I
guess
also
we'll
see
how
accurate
this
is.
Once
a
new
team
members
join
and
they'll
be
able
to
follow
these
steps.
I've.
A
Thanks
for
the
feedback
yeah,
the
next
thing
that
I
would
like
to
point
out
as
a
win
is
nothing
of
my
own
work.
It's
purely
Rob's
hard
work,
and
that
is
the
onboarding
designs
that
he's
created.
A
But
yeah
Rob's
done
a
great
job
of
creating
these
on-roading
screens
and
that
I'm
quickly
flicking
through
here
there's
a
lot
of
thoughts
that,
like
goes
into
everything,
Samus,
also
provided
some
very
good
feedback
and
guidance
on,
like
you
know
what
is
appropriate
and
what
we
should
and
shouldn't
have
and
yeah
for
someone
who
isn't
a
designer
I
think
this
is
like
really
fantastic.
A
I'm
gonna
speak
this
one
also
for
Max,
sorry
that
it's
just
like
a
podcast
with
he
on
here
this
one
since
Max
just
left
the
call.
This
is
something
that
I
as
a
friend
consumer
of
this
find
like
a
very
good
piece
of
work.
This
is
what
we've
just
talked
about
like
how
we've
LeapFrog
ahead
and
customization.
This
is
Max
Mr
that
adds
support
for
repository
configuration
files
inside
gitlab,
both
for
dashboards
and
for
visualizations.
A
It
means
that
we
now
basically
with
this
Mr
support
fully
customizable
dashboards.
It
follows
the
schema.
You
can
import
multiple
visualizations,
you
can
share
visualizations
across
multiple
dashboards
and
because
it's
just
repository
files,
we
have
all
the
supporting
Tools
around
that
via,
like
the
blob
editor
and
the
web
IDE,
to
create,
manage
delete
these
files
put
them
in
an
MR.
So
this
gives
us
a
great
job.
Jumping
off
point
to
you
know,
create
some
templates
added
in
here
and
yeah.
A
D
D
I
think
we'll
I'll
definitely
jump
in
and
try
to
build
up
parts
of
the
audience
and
behavior
dashboards.
Using
this,
this
looks
great.
A
Cool
well,
in
that
case,
I
think
we're
at
the
end
of
the
agenda.
This
anyone
has
anything
else.
They
would
like
to
add.
A
C
C
C
C
So
this
is
a
super
early
version
just
to
figure
out
things
at
the
moment,
but
I
think
we
can
bring
some
parts
of
it
one
to
one
in
a
sub
Mr
into
production,
so
that
we
would
be
able
to
already
play
around
with
data
and
basically
have,
at
the
end,
like
a
copy
and
copy
past
paste
part
where
you
simply
can
take
the
query
and
put
this
into
the
Yammer
file,
because
this
is
producing
already
that
query
and
the
head
model
is
to
because
right
now,
if
you
look
at
Cube,
the
only
table
that
you
have
is
jitsu,
which
doesn't
tell
you
anything,
it's
an
event
table
with
tons
of
events.
C
But
what
we
want
to
do
is
we
want
to
separate
already
but
different
event
types,
and
we
want
to
separate
by
different
click,
events
and
product
areas
and
all
those
things
and
I
think
giving
this
not
to
the
user
will
make
it
very
hard
for
them
to
understand
and
we
will
end
up
with
a
solution.
Okay,
this
is
a
query
Builder
that
is
super
powerful,
but
not
really
usable,
especially
for
the
early
stage
of
users.
C
That
was
a
user
session,
because,
based
on
that,
we
can
then
build
also
more
insights
into
users.
So
something
that
is
currently
possible
straight
away
would
be
all
the
user
activity
for
everything
else.
We
need
definitely
need
to
take
a
look
so
that
it's
feasible
on
the
long
run.
It
would
be
through
queries,
but
it
becomes
super
harsh,
very
early
on,
because.
D
B
C
And
this
is
by
the
way,
is
using
the
background
view
Cube
query
designer
already,
so
this
is
providing
me
through
the
end
point
through
and
that's
why
I
needed
to
edit
an
a
part
from
the
load.
Endpoint
also
I
made
that
end
point
and
a
dry
run
endpoint,
and
this
gives
me
already
the
data
on
what
is
possible
by
Cube
itself
and
I,
simply
abstracted
some
of
the
things
to
say.
C
Okay
I
want
to
have
page
views,
counted
I
want
to
have
this
for
all
pages
and
ideas
to
have
them
say:
Okay
I
want
to
count.
I
want
to
have
insights
just
on
a
very
specific
page,
so
this
would
be
also
a
possibility
because
we
can
get
a
distinct
from
the
cube
back
in
and
if
we
see
all
the
pages,
then
we
say:
okay,
that's
our
data
source,
our
general
data
source
and
we
can
go
into.
We
want
to
have
rather
page
views
over
time,
basically
by
day.
C
B
C
And
so
on,
so
you
can
also
say:
I
want
to
have
them
sliced
up
by
the
page.
Title
notice,
the
page
doc
path
in
reality.
C
D
C
You
go,
but
you
can
also
have
the
slicing
based
on
operating
system,
so
everyone
is
currently
using
internal
handbook
from
a
Mac
and
so
on,
and
this
is
then
basically
the
next
step
and
a
step
further
down
the
line.
We
can
also
say:
hey:
do
you
want
to
slice
up
the
data
by
two
elements
so
that
you
have
basically
two
Dimensions
that
you
can
say?
C
C
We
add
the
line
chart
that
we
are
currently
that
Dion
is
currently
working
on,
and
hopefully
a
state
bar
chart
and
so
on,
but
provide
already
way
more
direction
through
our
query
designer
compared
what
what
cube
is
providing
with
this
massive
feature
set,
but
basically
abstracting
even
on
another
layer,
anything
that
we
do
with
Jitsu
and
the
data
structured
there
so
that
we
have
also
browsers
and
and
so
on,
because
in
reality
this
was
would
be
one
field
that
is
called
past,
UA,
OS
or
browser
version,
for
example.
C
C
F
Because
what
I
really
like
about
this
is
the
fact
that
you
don't
have
to
make
a
code
change
to
see
a
change
in
what
the
data
that,
because
my
my
thinking
is
that
we're
going
to
see
a
lot
of
drop
off
if
it's
hard
to
do
data
exploration
right,
if
you
have
to
manually
edit
a
yaml
file,
make
it
commit
to
try
something
new
people
aren't
going
to
do
that.
They'll
use
a
visual
interface
like
this
I
think
it
looks
really
good.
Tim.
C
Think
the
big
big
Next
Step
will
be
defining
for
our
product
intelligence
for
some
tasks
that
we
we
get
pre-aggregated
sessions
and
with
free
aggregated
sessions.
We
can
do
all
the
classic
user
daily,
active,
weekly,
monthly
and
so
on
and
can
take
it
from
there,
but
everything
events
related
one-to-one.
We
can
already
build
into
the
product.
So
that's
currently
mine.
F
So
don't
we
have
Target
time?
Don't
we
have
time
stamp
values
in
our
data
currently
because
we
should
be
able
to
build
Dao
and
Mao
off
of
that
right?
Yes,.
C
F
Because
I
put
that
together
in
Google
Sheets
I
can
I'll
drop
a
link
to
it.
If
you
want
to
check
it
out
using
the
doc
host
as
well
as
that
time
stamp
field
and
the
source
IP.
D
Yeah,
so
that's
X
Mauser
does
are
possible.
It's
a
sessions
that
will
have
to
require
progregation.
D
But
yeah,
no
that's
exciting
stuff.
Well,
we'll
imagine
we'll
have
to
get
into
event,
taxonomy
and
studentization
for
that,
but
yeah
there's
a
lot
of
potential
there.
D
C
Can
but
all
those
huge
blocks
together
and
I
think
that's
that
that's
the
most
interesting
part
at
the
moment
is
really
that
we
are
very
close
with
a
couple
of
those
things
and
as
soon
as
we
have
everything
in
place,
we
can
start
with
Yammer,
but
also
take
another
look
that
we
work
closely
together
with
optimize
because
looking
at
their
needs
at
the
moment,
just
to
come
back
one
more
time
to
the.
C
Where
are
we
going,
is
really
that
we
can
maybe
really
take
a
look,
how
hard
it
would
be
to
create
and
all
those
custom,
dashboards
and
and
change
them
over
time,
because
that's
the
main
feature
that
they
will
need
and
what
they
are
looking
for
is
a
dashboard
where
you
they
have
these
Sora
and
Dora,
and
whatever
limo
Fish
Explorer
metrics
exactly.
C
But
what
they
want
to
have
is
like
an
executive
dashboard
as
they
call
it
so
that
you
can
basically
say
Okay
I
want
to
have
the
statistics
once
for
Project.
X
I
want
to
have
the
statistics
once
for
project.
Why
once
for
project
set,
so
that
is
nothing
that
could
help
them
really
without
having
some
sort
of
dashboard
edit,
and
it
simply
has
a
huge
flower
effect
that
we
can
present
and
use
this
for
the
game,
so
cool
yeah?
No,
it's
super
exciting.
C
D
All
right
and
if
there's
nothing
else,
then
wish
everyone
a
good
rest
of
your
Tuesday
rest
of
your
week
and
don't
forget
Friday's,
family
and
friends
day.