►
From YouTube: 2023-01-31 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
Let
me
run
to
my
screen
getting
some
thumbs
up
all
right,
hello,
everyone
and
welcome
to
the
product
analytics
sync
for
the
last
day
of
January
23.
I'll
kick
us
off
by
walking
the
ball
board
in
open
issues
we
have
the
first
one
is
ignore,
clickhouse
connection
string,
application
setting
that
is
assigned
to
Max
anything
to
mention
there.
No.
B
Just
push
the
fix
for
it,
but
let's
say
I
pushed
a
change
to
it.
To
see.
I
just
want
to
see
how
that
goes,
feel
free
to
attach
workflow
in
Dev,
because
I'm
looking
at
it
yeah.
B
Well,
yeah
I
mentioned
it
later
in
the
agenda,
but
there's
I'm
not
entirely
sure
how
to
fix
it
without
reworking,
while
other
session
stuff.
So
let's
discuss
in
a
bit
about
how
much
work
we
want
to
put
into
that
right
now
and
how
important
it
is
cool
sounds.
A
Good
then,
the
last
one
is
unassigned
for
at
product
analytics
application
setting
for
collector
host
I'm
guessing
this
is
also
related
or
maybe
not
anything.
C
No,
this
is
for
kind
of
the
instructions
that
were
pointing
to
the
wrong
host
and
and
I
have
a
later
point
to
kind
of
quickly.
Just
get
provide
an
illustration
of
how
the
Jitsu
images
are
different
in
terms
of
the
configurator
and
the
server
itself.
C
So
at
some
point,
I
submitted
a
merge
request.
I
haven't
gotten
back
to
it
yet,
but
there's
a
pretty
hacky
solution
in
terms
of
changing
the
URL,
but
that
doesn't
work
when
people
are
self-managing
their
clusters
and
decide
to
call
their
Edge
server
the
the
thing
that
actually
collects
the
events,
something
else
besides
collector.
C
So
this
is
a
additional
application
setting
that
we
would
need
to
Define
we're
not
using
it
anywhere
other
than
for
informational
purposes,
which
would
be
quite
useful,
especially
at
the
instance
level
to
be
able
to
say
hey
when
you
send
events,
you
need
to
send
it
to
this
host
and
not
the
configurator,
because
the
configurator
is
only
responsible
for
configuring
sources
and
destinations
and
API
keys.
So
that's
the
issue
for
that.
A
Sure,
thanks
for
adding
context,
then
we
have
two
planning
breakdown
issues.
This
API
to
retrieve
is
yeah.
I
will
take
a
look
at
this
again,
so
I
always
have
myself.
A
This
is
related
to
creating
a
back
and
way
of
retrieving
the
product
analytics
State
just
for
context,
then.
After
all,
you
have
the
next
one
for
update
learner
set
up
to
so
that
it
actually
publishes
the
packages.
D
Yeah
yeah,
that's
right,
so
I'm
working
on
it
I'm
investigating
the
solution
that
the
status
of
that
issue
is
actually
a
solution.
Validation,
it's
just
that
I
didn't
saw
it
in
the
world,
so
I
left
it
on
planet
breakdown,
but
I
I
just
noticed
that
we
have
a
couple
of
of
issues
on
the
open
column
which
are
in
solution
valuation,
so
I
updated
it
after
the
call
and
yeah
to
get
it
to
the
point:
yeah
I'm
working
on
eBay.
A
E
A
E
F
A
Cool
I
have
the
first
in
Dev
one.
This
is
adding
a
date
range
filters
to
the
dashboards.
I
have
the
front
end
working
also
demo,
this
later
or
during
a
I'll,
make
like
a
recording
and
post
it
on
the
slack
Channel
but
yeah.
We
also
have
a
journal
item
to
discuss
the
Blocker
in
terms
of
getting
the
queries
working
for
this.
A
The
next
one.
We
have
the
audience
dashboard,
I,
don't
know.
If
there's
anything,
we
need
to
discuss
here,
because
I
think
this
is
reliant
on
like
the
ux
bugs
and
polish
and
stuff
that
we
need
to
do
for
this.
C
A
Right
the
same
for
the
behavior
dashboard
I
believe
unless
there's
anything
yeah,
okay,
I'm
seeing
a
Notting
head
and
then
Max
you
have
the
next
one
yeah.
B
B
I,
don't
know
how
far
Sam
and
Dennis
I
guess.
We
should
probably
have
a
conversation
about
this
I've
sort
of
proposed.
The
two
possible
solutions
to
this
one
is
easy,
but
not
necessarily
fully
featured,
and
the
second
is
harder,
but
more
scalable,
so
we're
in
a
position
now
where
we
can
define
an
implementation
plan,
but
it'd
be
good
to
get
your
input
on
that
issue.
C
C
I
can
push
that
out,
but
I'm
verifying
I'm
testing,
basically
because
you
might
have
seen
in
the
channel
we're
talking
about
the
public
handbook
and
how
much
traffic
that's
receiving
and
so
I'm
kind
of
combining
this
with
or
this
has
to
be
changed
a
little
bit,
because,
ideally,
the
redis
servers
are
going
to
be
working
in
replication
mode
and
there's
going
to
be
more
than
even
one
of
those.
C
So
the
long
story
short
there
is
that
the
data
persistence
configuration
may
change
as
I
scale,
redis
out
to
be
replicated
and
multi-node
so
yeah.
C
The
other
one
is
a
competitive
analysis.
This
is
in
support
of
a
fiscal
year,
22
Q4
okr
in
terms
of
just
kind
of
performing
a
bit
of
analysis
to
see
if
there
are
any
quick
wins
in
terms
of
iterating
towards
that
this
doesn't
particularly
apply.
This
is
all
groups
that
have
been
performing
this
analysis.
C
It
doesn't
particularly
apply
to
product
analytics
because
we're
competing
with
ourselves
and
getting
off
off
the
ground
with
just
having
nothing
versus
something,
but
I
did
get
it
to
start
on
this,
to
compare
against
some
of
the
bigger
Solutions
out
there,
namely
mixed
panel
amplitude
and
Google
analytics,
and
we
can
revisit
that
with
other
point
Solutions
as
well
to
see
you
know,
once
we
get
out
to
the
customer
preview
or
even
out
of
beta
and
to
actually
you
know,
General
availability,
how
we
stack
up
against
them
and
what
we
can
do
to
to
kind
of
make
up
for
any
any
gaps
in
competitiveness.
A
Oh
sounds
insightful,
then
Axel.
You
have
the
next
two.
D
Yeah,
so
these
two
are
in
review.
Alongside
the
learner
related
the
the
publishing
related
issue.
D
We
have
like
all
of
the
schedule
and
SDK
issues
that
we
have
for
this
Milestone,
so
yeah
right
after
that,
I
probably
jumped
into
either
either
one
of
the
of
the
issues
that
we
have
ready
for
development
or
one
of
the
follow-ups
that
were
left
after
after
merging
the
the
onboarding
issues.
A
Well,
I
did
take
a
look
at
the
both
Mrs
for
this,
and
but
look
good
just
have
some
minor
feedback
about
like
yeah.
What
we
can
do.
D
E
Ahead,
I
need
to
just
to
reiterate
the
deployment
up
to
npm
as
a
manual
process,
so
once
those
two
are
emerged,
I'm
happy
to
handle
doing
that
for
now.
Until
we
get
this
learner
stuff
sorted.
D
E
Yep,
thank
you
Max
for
merging
that
this
morning
this
adds
to
the
dashboards
item
to
the
analytics
Sub
menu.
E
Our
existing
dashboard
listing
for
now
there
is
a
discussion
going
on
around
creating
a
separate
listing
and
migrating
everything
over.
So
that's
a
future
conversation
it's
behind
a
feature
flag,
which
is
also
documented.
So
if
you'd
like
to
enable
that
so
you
can
actually
have
a
menu
item,
feel
free.
B
This
is
done
in
verification.
We
need
to
get
the
funnel
schema
into
the
production
cluster,
so
I
can
actually
close
this.
It's
done
to
all
intents
and
purposes,
but
I've
not
been
able
to
test
it
in
production.
Yet
all.
C
Right
yeah:
let's
let
me
try
to
get
the
staging
cluster
put
up
together
first
and
then
we
can
test
it
there,
because
if
I
mean
we
could
test
it
in
production,
but
then
basically
something
goes
wrong.
Then
all
acute
requests
start
failing
so
yeah
that.
C
D
A
Or
I
think
we
can
skip
the
confidential
one.
You
might
need
to
also
edit
the
side
of
the
recording
event.
C
It's
pretty
generic
and
it
was
it's
confidential
just
because
it
was
during
the
internal
preview
and
happening
with
the
internal
handbook,
but
it
Max
I.
Think
generally,
you.
F
B
I
see
yeah
I
mean
in
terms
of
the
thing
it
fixed.
There
was
intermittent
errors
when
loading
dashboards,
due
to
it
being
over
generous
in
how
many
access
tokens
that
we're
generating
on
every
key
request.
So
we
we
reduce
that
scope
dramatically,
so
yeah
no
longer
happening.
E
Sorry
phone
call
I
had
to
take
the
next
yeah.
This
was
just
updating
the
documentation
to
make
sure
that
we
are
properly
documenting
the
stack
we
currently
using
what
feature
flags
are
being
used
and
where.
A
And
then
also
add
stack
to
production,
analytics
stocks,
cool
right,
I'll,
add
a
bookmark
and
we
can
carry
on
to
the
next
one.
The
next,
the
general
item,
that
is,
you
did.
C
Yeah
I'm
trying
to
resize
the
window
right
now,
it's
pretty
more
difficult
than
I
thought
there
we
go
cool,
so
I
just
wanted
to
quickly
kind
of
give
an
overview
of
the
Jitsu
like
infrastructure
in
production
versus
development.
C
The
tldr
but
I'll
just
show
a
quick
screenshot
of
it
as
well,
and
this
is
what
I'm
slowly
building
out
in
terms
of
data
persistence
is
that
you
have
a
couple
of
different
services
that
are
standing
between.
You
know,
user,
sending
events
and
the
click
house
data
store,
which
is
in
this
example,
the
destination
database
and
development
in
our
dev
kit.
C
Those
are
those
are
combined
as
one
image
and
developed
in
the
dev
kit
for
the
sake
of
Simplicity.
That's
why,
when
you
go
to
the
Jitsu
server,
you
just
add
slash
configurator
and
you
can
go
in
there
and
do
stuff
in
a
production
deployment.
You
don't
need
many
configurator
services,
because
all
you
need
to
do
is
just
Define
it
once
it
saves
it
in
redis
that
replicates
and
does
it
what
it
needs
to
do
in
a
cluster
environment,
and
then
the
server
is
actually
hit
redis
to
know.
Okay
I've
received
this
key.
C
Where
does
it
go?
They
all
go
to
clickhouse,
but
in
this
case
what
database
does
it
go
to,
and
so
in
terms
of
actually
scaling
this
out,
you
would
seldom
need
more
than
one
configurator,
but
you
would
scale
redis
out
because
that's
the
job
queue
and
that
stores
all
the
different
configuration.
C
That's
what
stores
all
the
like
analytical
data
as
well
in
the
dashboards
Fujitsu,
in
terms
of
how
many
data,
how
much
data
we're
receiving
and
then
you
would
actually
scale
out
the
Jitsu
I
call
them
the
edge
servers
or
the
servers
themselves
that
collect
the
events
and
send
them
out.
So
then
you
can
have
n
number
of
these
basically
to
to
support
how
much
traffic
you're
getting
you
know
per
second
per
minute,
and
then
that
would
sit
behind
a
load
balancer.
C
So
that's
why
I
created
the
issues
to
have
them
name
separately,
because
in
the
production,
our
environment
they're
at
different
hosts,
so
the
load
balancer
currently
is
like
collector
Dot
and
then,
whatever
the
stack
number
is
and
then
GL
productanalytics.com
and
then
the
configurator
is
just
a
single
server.
C
C
Cool,
if
you
ever
look
at
this
tier
actually
configurator
is
an
optional
step
here.
It's
just
easy
because
it
provides
us
an
API
for
us
to
as
we
do.
The
stack
initialization
thing
that
that
Max
and
everyone's
worked
on
in
terms
of
the
onboarding
flow
gives
us
an
easy
way
to
add
the
destinations
and
set
up
the
you
know
connection
for
that.
C
Alternatively,
you
can
just
Define
a
yaml
file
and
they
can
pull
the
servers
can
pull
from
that,
but
the
configurator
makes
makes
a
lot
easier
in
terms
of
we
actually
talked
about
that
a
little
bit
yesterday
in
terms
of
how
do
we
automate
that
and
the
configurator
actually
gives
us
a
lot
of
that
automation
for
free,
so
there's
a
little
bit
more
context
behind
that
I
will
stop
sharing
my
screen
and
yeah.
This
is
I,
think
a
shorter,
a
very
short
note,
just
so
I
wouldn't
forget
to
mention
it.
C
But
this
is
a
question
to
everybody.
I.
We
have
a
lot
of
references
to
Jitsu
in
our
code.
We
are
exploring
alternative
options,
whether
we
build
our
own
versus
you
know,
use
snowplow,
or
things
like
that.
C
So
I
will
rephrase
or
add
a
little
bit
more
detail
into
what
I
think
we
should
do
in
terms
of
like
internal
internal
references
to
Jitsu
I
think
we
should
remove
so,
for
example,
like
Jitsu
host,
for
example,
would
be
like
collector
or
collector
configurator
host,
or
something
like
that
now
for
the
purposes
of
what's
user
facing
it
would
be
beneficial
if
they're
standing
up
their
own
clusters
like
if
we
tell
them
what's
the
collector
host,
and
we
have
nothing
in
our
infrastructure
that
says
collector,
then
that
would
be
confusing
the
the
main
reason
behind
this
is
I,
wouldn't
want
us
to
have.
C
You
know
this
database
column
called
Jitsu
post
when
it's
like
the
snowplow
collector
endpoint
at
some
point.
So
if
we
can
generalize
it
now,
the
same
way
we
can
kind
of,
like
you
know,
rename
things
from
widget
to
panel
earlier
and
I.
Think
it'll
save
us
a
little
bit
more
work
later
on
so
I
would
say
like
internal
references
to
Jitsu,
we
would
update
but
I'm
curious
what
everyone's
thoughts
on
that
would
be.
B
I'm
not
entirely
convinced
because,
like
you
say,
we're
saving
something
called
Jitsu
host.
That
is
what
it
is.
It
is
jitsu's
host,
nothing
to
say
we
couldn't
store.
We
couldn't
have
a
database
column
for
both
that
and
for
snowplow,
and
then
the
the
application
logic's
job
is
then
to
figure
out
which
one
of
those
to
use
rather
than
having
collector
hosts,
because,
like
you
say,
it's
not
entirely
clear
what
that
is
referring
to.
If
that
makes
sense,.
B
And
I
think
that's
right
and
yeah
I
think
our
front
end
shouldn't
refer
to
Gypsy
at
all.
As
far
as
the
end
users
are
concerned,
who
are
looking
at
the
dashboards?
Jitsu
shouldn't
exist
as
a
term,
but
in
terms
of
Administrators
who
are
setting
up
connections
to
various
Services.
The
Jitsu
host
is
the
host
for
Jitsu
and
there's
nothing
to
say
as
well,
but
every
service
we
connect
to.
So
let's
say
we
used
a
different
something
like
snowplow
that
it
would
be
a
hostname.
B
You
know
it
might
be
like
a
Unix
socket
or
something
like
that
or
a
connection
string.
That
includes
both
some
sort
of
login
details,
a
database
and
a
port
number,
and
so
we
might
have
different
validations
on
that
field
as
well
so
I'm
just
thinking
if
we
over
General
sized,
that
could
be
an
issue.
C
B
Yeah,
we
might
get
rid
of
that
entirely
if
we
move
to
snow
plow,
exactly
yeah
so
like
if
we're
just
using
collector
connection
strings.
So
we
can
assume
you
know
if,
because
we
all
know
that
they're
going
to
be
roughly
the
same
format
and
they're
going
to
validate
the
same
way
and
they're
going
to
obtain
the
same
information,
that's
fine
and
that
works
for
click
outs,
but
it
definitely
doesn't
work
for
Jitsu,
because
we've
got
configuration.
B
Urls
we've
got
collect,
URLs,
we've
got
project
names,
we've
got
project,
IDs
yeah,
there's
a
lot
more
possibilities
there
and
I.
Don't
know
what
we
need
for
for
snowpower
either
so
yeah
the
the
MRI
I've
got
open
is
to
remove
all
the
user-facing
references
to
Jitsu,
which
I
think
is
yeah.
I
think
we
should
do
because
that's
just
confusing
I
think
the
the
non-user
facing
stuff
might
need
some
more
thought
depending
on
where
it
is
we're
hoping
to
go.
Yeah.
C
Then
we
can
keep
the
reference
into
Jitsu,
then
and
at
least
add
that
additional
field
so
that
we
know
that
there's
a
difference
between
the
two
different
Jitsu
services,
so
I'm
good
with
that.
Unless
anyone
else
has
any
other
thoughts
on
this.
C
Yeah,
because
if
you
go
on
like
the
query
designer,
for
example,
you'll
start
seeing
like
Jitsu
effectively
namespace
dimensions
and
measures
in
your
cluster
configuration,
you
see
like
a
jitsujs
for
the
schema,
we
have
a
table
called
Jets.
Do
we
yeah?
We
have
a
table
called
Jitsu.
So
like
things
like
that,
yeah,
that's.
B
C
B
As
an
administrator,
if
I'm
one
of
these
I
don't
know,
appends
that
doesn't
read
the
documentation,
I
want
to
go
into
admin
and
it
says,
enter
your
Jitsu
installation
information.
I'm
like
okay,
well,
I,
better,
go
and
install
Jitsu.
Then
hopefully,
you've
been
slightly
more
methodical
than
that,
but
at
least
it's
obvious
what
it
is
that
we're
looking
for.
B
A
Dots
so
it'll
be
there'll,
be
two
Mrs,
but
but
will
it
change
to
we'll
still
have
a
namespace
or
like
a
prefix?
So
it
will
be
like
collector,
DOT,
first
UA
family,
because
I'm
just
thinking,
because
we
also
have
like
sessions
and
potentially
more
that's
being
added.
So
is
everything
going
to
be
collapsed
like
without
that,
first
bit
or
yeah.
A
C
Events
or
attract
events
I'm,
not
particularly,
we
just
need
to
generalize;
it
is
the
main
point
and
events
I
think,
is
an
accurate
representation.
These
are
all
events
but
check
in
with
Max
to
see
how
he
feels
about
it.
Now
that
he
said.
C
Did
you
panic
quit.
B
Max
I
have
no
idea
what
happened
there.
I
think
Zoom
just
completely
crashed
sorry.
What
did
I
wasn't
needed
for
anything
else?
In
that
conversation,
no.
C
B
Yeah
we're
going
to
rename
any
all
of
that
to
tracked
events,
so
I,
don't
know
how
much
of
what
you
heard
before
I
disappears.
So
there'll
be
two
Mrs
one
to
update
the
schema
and
then
one
to
update
the
currently
built-in
dashboards
in
gitlab
itself
to
refer
to
those
new
schemas.
Okay,.
B
Sorry
I'm
just
putting
Zane
back
in
my
place,
so
yeah
yarn
quite
roughly
pointed
out
that
sessions
aren't
working
with
date,
ranges
at
the
moment
and
that's
because
I
followed
cubes
tutorial
on
how
to
say,
Obsession
analytics,
which
is
not
good
or
click
house,
so
it
it
works.
But
it's
I
didn't
realize
that
that
was
a
thing
it
didn't
do.
B
So
there
may
well
be
a
clickhouse
specific
way
to
solve
this.
I,
don't
know
what
it
is
yet
I'm
more
than
happy
to
spend
time
and
figure
that
out,
but
there's
one
back-end
Engineers.
So
it's
more
a
case
of
priorities
and
how
much
time
we
want
to
spend
rewriting
sessions
so
that
we
can
use
date
range
filters,
I'm
happy
for
it
to
be
top
priority.
I
just
wanted
to
steer
from
the
rest
of
the
group
on
there.
B
C
Sam
I,
don't
know
if
you
want
us
to
like
reevaluate
tomorrow
during
like
pre-planning
or
I.
Think
exporting
is
pretty
important,
but
then
also
like
the
date
range
is
kind
of
a
big
control
for
all
the
dashboards.
F
Yeah
so
I
put
this
in
my
comment
on
the
issue.
I,
don't
think
this
is
necessarily
something
we
should
consider
a
bug,
but
it
is
a
piece
of
Feature
work.
We'll
want
to
prioritize
pretty
highly
I'll
need
some
time
to
think
about
where
that
would
Shake
on
the
stack
rank.
To
give
you
an
answer,
but.
B
F
In
my
mind,
it's
not
a
let's
drop
everything
work
on
it
right
now,
unless
I'm
missing
something,
otherwise,
it
seems
like
it'll,
be
close
to
the
top
of
the
feature
list,
but
not
a
P1
S1
sort
of
drop
everything
urgent
issue.
B
That's
fine
that
that
there's
an
element
in
in
here
of
I
don't
entirely
know
what
I'm
doing
so,
there's
going
to
be
a
fair
amount
of
thanks,
Rob,
there's
gonna
be
okay,
yeah
of
sort
of
figuring
out
how
to
solve
this
in
the
same
way
with
funnels
so
yeah.
That
sounds
good.
C
I
would
say
it's
not
an
S1
bug
for
it
perhaps,
but
it
is
a
P1
feature
because
I
think
you
know
based
on
if
you
were
to
set
up
instrumentation
right
now,
you're
just
querying
every
like
all
time
right
now.
So
it's
a
pretty
critical
piece
of
functionality.
But
if
we're
already
Midway
through
like
renaming
stuff
away
from
Jitsu,
then
it
doesn't
I,
don't
know
if
it's
worth
like
stopping
everything
is
that's.
Why
I'm
not
I
personally,
don't
feel
like
it's
a
drop
or
everything
kind.
B
A
I
was
just
about
to
say
that,
depending
on
how
quickly
this
gets
fixed,
an
option
that
we
can
consider
is
I
can
push
this
feature
still
because
it
is
behind
a
feature
flag.
Two
of
the
audience
widgets
will
be
broken.
If
you
select
the
date
range,
but
I
mean
that's,
maybe
still
fine,
because
then
we
can
at
least
show
what
we've
got,
and
it
will
be
a
good
reminder
to
fix
it.
A
Well,
in
that
case,
we
only
have
one
read:
only
item
left
so
I
think
that's
it
for
our
agenda.