►
From YouTube: 2023-04-18 Product Analytics Group 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
Hello,
everyone
and
welcome
to
the
April
18th
product
analytics
group.
Sync
I'll
go
ahead
and
start
sharing
my
screen.
We
can
take
a
look
at
the
billboard
and
then
get
through
the
agenda.
A
All
right,
hopefully,
everyone
can
see
my
screen
and
yeah,
so
open
Planning
issue
will
be
closed
out
as
soon
as
I
think
today
or
tomorrow.
That
should
be
closed
out
soon.
A
couple
of
open
issues.
They
think
fetching
dashboard
configurations
from
the
back
end
still
in
scheduling
so
I
assume
this
hasn't
been
started
yet.
A
Logging
and
implementing
CH
proxy
kind
of
in
a
holding
pattern
until
we
have
more
that
we
need
out
of
it.
So
we
can
probably
start
scheduling
those
out
or
yeah,
let's
catching
those
a
little
further
out
without
any
visualizations
just
panels.
The
dashboard,
which
is
something
we're
still
validating,
and
then
we've
got
a
bug
that
has
not
been
moved.
So
we'll
talk
about
the
16
year
planning
issue
in
a
bit
and
then
we've
got
what
are
these
issues
here?
That
one
I
got
first
using
onboarding
flow
I'm,
not
really
sure
about.
A
A
Then
I've
got
to
determine
where
to
put
the
instrumentation
details
out
to
the
dashboard
listing,
which
I
believe
we've
actually
figured
out
where
we
want
to
put
this
Kevin's
out
anyway,
but
I
believe
we've
come
to
a
decision
about
this
I
think
we're
going
to
move
it
to
settings
analytics
yeah,
so
I
think
there's
an
issue
for
that
which,
yes,
there
might
be
still
some
conversation
to
have
around
that.
So
we'll
dig
into
that.
We
saw
the
empty
state
for
single
visualizations
which
need
to
design
and
then
upgrading.
A
A
We've
got
this
issue:
it's
how
to
receive
some
design
work
in
terms
of
a
visual
indicator
to
dashboard
panels
when
you're
in
edit
mode
to
make
that
a
little
bit
more
obvious,
which
is
ready
to
pick
up
and
then
and
then
we'll
move
on
to
in-depth
tracking
usage
of
product
analytics
weekly,
active
users
and
projects
emitting
data.
Max.
Anything
you'd
like
to
call
out
here
yeah.
C
We've
been
thinking
this
around
snow
plow
work,
there's
four
match
tricks
that
need
to
be
implemented,
one
of
which
is
past
products.
Intelligence,
review,
I
just
need
to
write
a
spec
for
it
and
then
I'll
work
on
the
other
three
throughout
the
milestone.
A
A
C
A
You
yeah
no
worries.
We've
got
improving
management
of
Secrets
within
the
analytics
stack,
which
Rod
has
but
he'll
be
out
he's
out
at
the
moment.
So
we'll
check
in
on
that
later.
D
A
Then
we've
got
putting
an
add
dashboard
button
on
the
analytics
listing
pages,
also
includes
kind
of
the
adding
or
creating
a
new
dashboard
concept
with
the
dashboard
designer
on
anything.
You'd
want
to
call
out
here.
D
Yeah,
this
is
almost
ready
for
review.
It
went
it's
like
at
the
bottom
of
my
priority
second
moment
so
as
soon
as
my
other
issues
are
merged
or
done,
I'll
get
back
to
this
great.
A
Let
me
move
this
issue
back
because
I
keep
saying
the
same
thing
for
that
one
and
then
Alan
you've
got
allowing
users
to
connect
their
own
product
analytics
stack
at
the
project
level.
Anything
you'd
like
to
update
us
on
here.
E
I'm
I've
currently
got
an
MR
up
for
that
and
I'm
going
to
try
to
get
it
ready
for
review
today.
So
still
might
end
review.
But
let's
get
in
there.
D
Yeah,
so
this
is
removing
finally,
the
product
analytics
specific
listing
so
that
we
can
hopefully
avoid
some
confusion
around.
Why
do
we
have
two
dashboard
listings?
Yeah?
It's
interview.
I
just
saw
that
the
pipeline
notified
me
that
I
missed
a
controller
spec,
so
I'm
going
to
push
that
and
yeah
should
be
good
for
review
again.
Awesome.
A
C
Words
there
we
are
very,
very
close:
Allen
has
just
approved
it,
but
also
pointed
out
that
there's
merge
conflicts
so
I'm
as
we
speak,
trying
to
resolve
those
once
that's
done.
I
will
hand
it
off
to
a
maintainer
who
hopefully
will
wave
it
through
and
we
get
it
merged
today.
Awesome.
A
Metal
I
think
unblock
a
number
of
other
issues
to
to
wrap
up
or
not
wrap
up,
but
just
to
progressively
snowplow
integration
service,
so
yep
good
stuff
we've
got
fixing
transitioning
pods
with
persistent
volume
claims.
I
think
this
might
be
related
to
what
Helio's
working
on,
and
this
could
be
closed
out
because
I
think
Rob
created
this.
As
sorry
I
mean
say
that
Rob
created
this
improved
deployment
using
staple
sets
as
a
finding
of
this,
but
I'll
double
check
that
and
close
that
out.
B
He
actually
has
an
MR,
so
okay
kind
of
we
are
like
doing
multiple
things
which
I
can
solve
the
same
way.
So
I
think
I'll
talk
to
him
when
he's
back
yeah
awesome.
A
All
right
and
then
in
verification
we've
got
upgrading
the
funnels
API
to
return
snow
block,
compatible
SQL
I!
Don't
is
there
anything
you
wanted
to
talk
about
here.
E
That
one
is
only
in
verification
because
we
haven't
turned
on
the
flag.
Yet,
okay,
all.
A
Right
sounds
good,
trying
to
think
I
think
we.
A
D
Yeah
I
have
a
general
item
to
quickly
demo
that
so
I'll
talk
about.
It
then
sounds.
A
Cool
so
I
just
kind
of
wanted
to
give
a
kind
of
recap
of
what
we've
been
doing.
What
we're
working
on
and
kind
of
combine
that
into
recent
developments
with
you
know
the
company
pushing
into
Ai
and
things
like
that
to
kind
of
help
us
just
one
getting
a
refresh
looked
up.
A
You
know
where
we're
at
as
a
group,
and
then
you
know
what's
coming
up
ahead,
so
you
know
not
much
has
changed
in
terms
of
the
main
priorities
in
terms
of
getting
what
we've
built
so
far
out
to
customers,
and
so
as
you've
seen
from
previous
group
sinks,
we've
got
customers
identified
in
terms
of
who
we
want
to
bring
onto
that.
There's
some
conversations
I'm
having
this
week
to
be
able
to
help
us
facilitate
actually
being
able
to
onboard
customers
specifically
handling
Red
Data.
Since
customer
data
is
Red
Data.
A
Given
that
we
don't
have
infrastructure
support,
officially,
you
know
I
think
it'd
be
one
thing:
I'm
trying
to
speak
with
infrastructure
about
is
the
possibility
for
us,
whether
it's
one
or
a
select
number
of
individuals
to
be
able
to
manage
our
own
production
infrastructure
and
what
would
be
required
to
be
able
to
handle
customer
data
and
production
so
that
we
continue
to
get
this
out
to
customers,
get
their
feedback
and
really
get.
A
At
the
same
time,
we
still
want
to
continue
to
make
the
experience
better
from
our
own
perspective,
so
bringing
in
the
dashboard
designer
which
Sean
is
already
working
on
what
you've
seen
of
the
visualization
visualization
designer
completing
that
experience,
so
that
customers
are
able
to
self-serve
and
really
use
leverage.
You
know
custom
dashboards
to
find
whatever
they
need
and
then,
as
you've
seen,
Alan's
been
working
on
bringing
your
own
cluster
and
then
we've
got
additional
things.
A
We
want
to
work
on
in
terms
of
allowing
customers
to
pull
their
data
out
as
they
need
to
and
then
a
whole
new
hose.
A
whole
host
of
other
features
that
we
haven't
even
gotten
into
in
terms
of
experimentation,
feature
flags
and
session
data,
and
things
like
that.
A
A
So
this
is
classified
as
a
priority:
zero,
meaning
that
you
know
this
is
a
big
shift
for
the
company
to
really
prioritize
in
terms
of
the
how
and
why
there
are
a
number
of
presentations
out
there
I've
linked
Tim,
which
gives
them
the
perspective
of
you
know,
engineering,
but
also
how
we
can
get
into
that
as
well.
A
A
We
also
want
to
continue
building
new
features
and
expanding
the
flexibility
that
we
have
with
bringing
your
own
cluster
and
things
like
that,
but
at
the
same
time,
there's
a
lot
of
opportunities
to
apply
AI,
assist
or
workflows
to
the
work,
we're
building
the
features
we're
building
right
now,
so
I've
called
out
a
couple
like
for
high
level
ones
in
terms
of
natural
language,
querying
Trend
analysis
inside
generation
forecasting,
and
there
are
already
efforts.
A
Efforts
happening
right
now
that
we're
applying
at
gitlab
so
it'd
be
interesting
to
see
how
we
can
apply
that
with
the
different
data
set
and
see
how
we
can
make
that
useful
for
customers,
but
anyways
check
out
the
presentation.
There's
an
epic
I've
linked
as
well
in
terms
of
possible
ideas.
So
if
you
haven't,
please
feel
free
to
chime
in
and
anyone
anyone's
ideas.
Okay
back
are
welcome,
but
I
just
want
to
kind
of
give
a
you
know.
A
It's
been
a
few
Milestones
we've
had
a
few
months
with,
since
the
realignment
and
things
like
that,
and
so
I
just
wanted
to
give
a
refresh
perspective
in
terms
of
what
we're
doing
and
why
it
matters.
C
Yeah
so
as
Dennis
quite
well,
it
went
out
to
me
last
week
we're
moving
to
snowplow,
but
what
we
haven't
done
is
make
the
built-in
dashboards
this
so
the
audience
and
the
behavior
dashboard
that
we've
created
won't
support.
The
snowplow
schema
as
they
currently
stand
so
demonstrate
the
issue,
and
the
question
really
is
whether
or
not
at
this
stage.
We
want
this
to
be
a
front
end
or
a
backhand
task
service,
a
front-end
task.
C
We
just
rewrite
the
existing
dashboards
to
use
new
schema
or,
if
we
sort
of
skip
a
step
and
head
to
straight
to
implementing
these
from
the
back
end.
So
we
Define
the
dashboards
in
yaml
and
then
allow
these
to
be
read.
C
I,
don't
really
have
a
strong
opinion
on
this.
From
a
brief
look
at
yarn's
response
and
from
what
I
think
Dennis's
writing
it
looks
like
this
might
be
a
back-end
task.
Instead,
which
is
fine
I,
just
it
depends
who's
going
to
do
it
when
we're
going
to
do
it
and
who's
got
capacity
for
it.
A
Yeah
so
John
did
you
want
to
look
as
your
response.
First
I
know
it's
kind
of
based
off
of
my
response
so.
A
So
what
I
suggested
in
the
issue
is,
we
know
we
have
so
for
for
full
context
for
everyone
to
wear
right
now
we
have
all
of
our
dashboards
visualizations
hard-coded
as
Json
in
the
front
end,
and
you
may
have
seen
some
issues
where
we
want
to
actually
start
fetching
those
configurations.
Much
like
we
do
for
custom
configurations
from
the
back
end,
and
so
we
have
an
issue
which
we
saw
on
the
billboard
which
just
hasn't
been
picked
up
yet
in
terms
of
like
using
the
backhand
as
the
source
of
Truth.
A
But
while
we
have
the
snowplow
integration
going
on,
we
refer
those
those
columns.
Those
attributes
are
referred
to
differently
and
when
it's
stored
in
snowplow
so
effectively,
we
have
to
either
duplicate
that
or
do
something
else,
and
so,
while
duplicating
that
makes
sense,
and
we
have
this
feature
flag.
It
seems
a
bit
excessive
in
my
opinion,
to
have
all
these
duplicates
and
then
clean
up
when
we
know
there's
an
also
a
goal
to
get
to
the
back
end,
and
so
what
I've
suggested
is.
A
While
we
have
the
Jitsu
related
dashboards
and
visualization
configurations
in
the
front-end
hard-coded,
we
should
just
use
the
opportunity
for
snowplow,
and
you
know
I'm
going
I'm
more
than
happy
to
admit
that
it's
a
scope
creep,
but
you
know
we'd
be
hard-cutting
these
dashboards
in
the
back
end
as
yaml
to
be
compatible
with
snowplow
and
I.
Think
that
just
helps
us
build
a
little
bit
more
efficient
in
terms
of
okay.
We
don't
have
to
create
duplicate
files
that
we
know
we're
going
to
throw
away
anyways.
A
We
get
to
our
goal
of
being
able
to
read
from
the
dashboard,
which
I
know
they're
being
able
to
read
the
dashboard
configurations
from
the
back
end,
which
I
know
there
was
some
confusion
previously
about
like
whether
that
would
require
schema
changes
or
not,
which
is
simply
not
true
right
now,
so
I
just
think
it
would
be
more
efficient.
So
that
was
a
really
long
way
of
saying
that.
C
And
that's
fine
with
me.
The
only
thing
we
need
to
think
of
is
that
the
reason
that
they're
hard-coded
currently
is
because
they
should
exist
in
all
projects
right,
so
there's
unanswered
questions
at
least
I
think
they're
unanswered
right
now
as
to
how
we
store
those.
So
you
know
we
we
not
really
in
the
business
of
adding
files
to
customers
repositories
for
them,
so
we're
gonna
have
to
write
them
as
yaml
files
that
we
store
in
the
back
end
and
just
sort
of
add
to
the
processing
class.
A
That
would
be
it,
so
they
would
still
have
to
be
hard-coded
right.
Otherwise,
we'd
have
to
put
them
in
the
stack
or
something
or
you
know,
add
them
to
the
project,
and
that
just
adds
a
lot
more
steps
than
is
necessary.
I
feel
so,
ultimately,
it
doesn't
change
the
core
principle
of
that.
The
fact
that
we
have-
and
they
say
it's
by
git
lab
like
we
have
pre-builds
that
are
just
part
of
our
code
base.
C
Right,
in
which
case
on
that
issue,
I
currently
wrote
I
think
it's
good
to
go
young.
What
do
you
think
disregard
that?
How
we
write
the
implementation
plan
based
on
what
we've
just
discussed
and
then
ping
you
about
to
get
your
thoughts.
D
Cool
yeah
one
thing
I'd
like
to
note
there
is
I
think
we'll
need
a
new
issue,
that's
specific
for
the
visualization
designer,
because
we'll
also
need
it
to
be
aware
of
the
snowplow
flag
to
be
able
to
set
the
parameters
like
the
measurements
and
stuff
using
the
snowplug
prop
snow
plow
properties,
rather
than
the
existing
jizzu
ones.
Yeah.
A
Yeah
visualization
design
is
going
to
need
a
huge
update,
anyways
and
as
I'll
get
into
the
160
issue
as
well.
You
might
have
seen
an
issue
where
we
actually
want
to
take
away
the
entry
points
the
visualization
designer
for
now,
just
because
it's
not
a
complete
user
workflow
and
then
with
the
snowplow
changes.
It's
gonna
probably
break
more
so
so
we
we
will
update
that
accordingly.
For
sure,
I
will
take
that
upon
myself
to
create
the
issue
for
that.
A
All
right,
then,
I
have
a
couple
more
just
kind
of
advisory
things,
and
then
we
can
get
into
Jan's
show
and
tell
just
just
signal,
boosting
the
planning
issues,
a
lot
of
stuff
added
there
really
to
the
snowplow
integration,
infrastructure
updates,
and
things
like
that.
A
So
if
the
should
be
plenty
of
vicious
to
pull
from,
but
if
there's
any
questions
thematically,
what
we're
doing,
especially
since
I've
kind
of
just
given
an
update
on
where
we're
headed,
please
let
me
know
I'm
happy
to
provide
more
additional
context
there
and
then
finally,
related
to
the
above.
A
With
regards
to
AI,
you
may
have
seen
some
people
get
asked
to
do
fall
of
the
sun
coverage
as
far
as
writing
or
reviewing
merge
requests,
and
so
I
will
definitely
let
you
know
as
soon
as
I
can
in
terms
of
your
involvement
in
that.
But
if
it
happens,
just
wanted
to
clarify
that
that's
a
priority,
zero
above
what
we're
doing
right
now,
until
at
least
we
can
get
to
the
point
where
we're
working
on
our
own
AI
experimental
features,
but
I
just
wanted
to.
D
All
right
can
everyone
see
the
dock?
Oh,
so
this
is
a
setup
project
as
I'm
all
as
I'm
sure
you're
all
well
aware
of
ignore
the
empty
name
there.
That's
me
trying
to
break
the
save
dashboards
feature
that
I'm
currently
working
on.
D
D
If
you
have
any
ideas
around
this,
please
feel
free
to
share
it
with
the
group,
because
it
is
a
ongoing
question
about
like
how
this
should
actually
look,
and
this
does
not
really
comply
or
fit
in
with
the
design
precedent
that
we
have
at
gitlab,
specifically
that
we
have
this
grayed
out
feature
item
here,
but
anyway,
I
just
wanted
to
quickly.
Take
you
through
the
flow.
D
So
if
a
user
lands
on
the
analytics
dashboard
instead
of
showing
a
404,
they
actually
see
it
and
we
tell
them
that
hey.
They
need
to
set
it
up.
First,
going
through
the
stages
it's
going
to
take
a
while
and
what
users
can
also
do
and
to
support
multiple
users
using
the
same
page
and
they'll
like
everyone
will
basically
get
the
same
state
because
we're
now
pulling
it
from
the
back
end
as
the
main
source
of
Truth.
D
So
clicking
back
on
it
like
multiple
people
can
basically
collaborate
on
like
setting
up
projects
or
setting
up
product
analytics
on
a
project
and
yeah
I'm
not
going
to
go
through
the
steps
of
actually
creating
events.
But
basically,
after
an
event
has
been
received.
Users
will
land
back
onto
the
listing
and
they'll
see
the
audience
and
behavior
dashboards.
A
After
I'm
looking
forward
to
not
being
able
to
or
not
having
to
add
hyphen
slash
product
analytics
dashboards
to
try
to
get
to
where
I
go,
so
we
can
finally
complete
that
flow.
So
looks
good
awesome,
then
anything
anyone
else
would
like
to
talk
about
before
we
call
this
meeting.
A
All
right
well
have
a
good
rest
of
your
Tuesdays
rest
of
your
week.
See
you
all,
maybe
later
in
this
AMA,
otherwise
take
care.