►
From YouTube: Manage:Analytics Weekly 2020-06-09
Description
The Analytics group briefly walks the board, then has a Q&A about the new Generic Reports feature concept.
A
All
right
welcome
everybody
to
the
June,
9th
2020
analytics
weekly.
So
today
we
have
a
little
bit
of
a
special
agenda:
we're
gonna
kind
of
quickly
walk
the
board
and
then
get
into
the
main
item
of
the
show
here,
which
is
a
QA
on
a
generic
analytics
report.
So
there
are
a
bunch
of
FY
eyes
which
we
won't
verbalize,
but
many
of
them
are
interesting.
So
please
take
a
look
and
now
I'll
just
hand
it
over
to
John
Mason
to
walk
the
board.
C
B
C
A
chat
with
him
today
and
he
mentioned
that
most
of
the
stuff
is
kinda
ready
in
a
week
Ammar
and
he
is
about
to
speed
things
down
into
smaller
Emerson
and
give
you
that
much
okay
and
he
will
try
to
test
it
with
my
changes
to
see
if
we
painted
a
she
is
working.
So
yeah
I
just
told
him
ping
me
when
something
is
not
working,
so
I
can
fix
it
quickly.
C
E
A
A
E
E
Was
I
just
noticed
that
the
the
filter,
sorry,
the
issue
we
were
just
discussing-
add
filter
results,
control
to
goo,
PSA,
wasn't
on
this
board
and
I
just
checked
the
others
trying
to
look
at
why
and
it
was
missing
a
priority
label.
So
I
don't
know
if
we
want
to
correct
that
or
if
there
are
other
issues
that
are
missing
from
this
board.
A
good.
E
C
A
E
A
B
I'll
just
make
one
brief
comment
as
we
transition
today,
and
that
is
that
I
did
finally
get
all
of
the
next
up.
Labels
cleaned
up,
as
well
as
the
work
breakdown
labels
and
needs,
estimate
labels,
and
so
on
for
things
that
were
old
and
I
had
some
difficulty
removing
labels
in
bulk.
If
there's
a
somebody's
got
a
great
tip
for
how
to
do
that,
I'd
love
to
hear
it
so
I
wound
up
using
in
an
ice
box
label
in
a
board
to
sort
of
remove
the
old
stuff
and
into
this
ice
box
category.
B
E
I
can
verbalize
departments
question
then.
So.
Are
there
any
plans
not
having
subpages
for
a
particular
report,
page
anytime,
soon,
Martin's,
particularly
interested
in
the
drill
in
functionality
of
report
as
our
analytes
are
currently
enabled.
The
enable
drill
doesn't
support
by
updating
a
data
table
based
on
any
filters
and
or
on
a
selected
charts
item
other
get
a
lot
of
features.
On
the
other
hand,
support
drill
and
functionality
via
sub
pages
in
I,
selecting
something
on
one
page
would
not
update
the
current
page
but
redirects
face
and
client-side
to
a
sub
page.
B
That's
a
great
question:
yeah
yeah.
So
let
me
replay
the
question
to
make
sure
that
you
know
I've
understood
you
and
Martin
since
you're,
not
here
to
correct
me.
You'll
at
least
know
that
I'm
answering
the
wrong
question:
the
you're
asking
hey
if
I
wanted
to
slice
and
dice
the
chart
that
is
just
or
the
data
that
is
on
the
reports
page.
Would
it
take
me
to
get
a
further
page
to
see
some
subset
of
that
data?
B
B
I
might
be
on
a
brand
new
dashboard
capability,
several
months
from
now
and
clicked
it
on
a
chart
there
and
when
I,
where
I
would
have
landed,
would
be
the
reports
page
and
that
reports
page
gives
me
access
to
the
the
chart,
the
data
behind
it
via
you
know,
removing
it
or
downloading
the
CSV.
It
allows
me
to
do
further
filtering
and
so
on.
B
The
sort
of
idea
that
we
had
about
clicking
on
a
bar
in
the
chart
and
filtering
a
data
table
below
it
that
we
have
an
issue
analytics
or
I've,
been
working
on
an
issue
analytics
all
that
kind
of
capability
would
live
on
the
report
page.
So
there
would
no
be
not
yet
a
further
drill
down.
That
said,
the
qualification
is
that.
D
B
Imagine
a
future
in
which
I'm
looking
at
a
report,
page
and
I,
want
to
see
some
subset
of
the
data
there
and
I
know
that
I
want
to
come
back
to
it
again
and
again.
In
that
case,
I
might
not
I
might
want
to
do
more
than
just
filter
it.
For
the
moment,
I
might
want
to
save
that
the
state
of
that
report,
page
as
it
is
as
a
new
report
which
I'm
gonna
save
for
my
future
reference
or
include
in
a
dashboard
somewhere
else,
so.
B
E
Your
point
about
that
so
I
think
that
addresses
Martin's
question,
at
least
based
on
my
understanding
of
what
he's
asking
I,
don't
know
what
the
impact
it
has
based
on
our
usage
of
your
router
and
on
the
architecture.
But
you
mentioned
that
the
report
page
would
lead
to
potentially
another,
but
not
a
sub
one,
but
it
wouldn't.
It
would
still
be
the
same
page
right
just
a
different
set
of
data
based
on
the
same
right.
B
B
E
B
With
regard
to
the
routing
question
that
said,
we
have
kicked
around
the
idea
of
saying
well
the
elements
on
that
page,
the
Jason
payloads
for
the
elements
on
that
page,
such
as
the
data
table
Series
1
in
the
chart
versus
series
2
in
the
chart
versus
series
3
in
the
chart.
Those
might
be
you
know
a
step
below
that
the
slug
to
get
those
particular
you
know
Jason,
Palos
or
whatever,
but
but
there
isn't
really
a
destination
below
that.
E
C
I'm
trying
to
finalize
the
first
back-end
issue-
and
here
I
have
a
question.
So
it's
really
cool
that
we
add
more
charts
to
simple
charts
to
give
WI,
and
my
question
is
about
the
specification,
the
mo
file
that
we
kind
of
describe
how
the
charts
should
look
like
what
kind
of
data
source
they
are
using
and
the
question
is:
can
we
maybe
work
on
the
EMF
at
their
distance
layer?
You
know
where
you
store
the
mo
file
a
bit
later
until
we
actually
have
more
charts,
ready
and
based
on
the
findings.
C
B
So
I
have
an
answer
in
mind
for
you
Adam,
but
before
I
jump
to
that
I
just
want
to
make
sure
I
understand
sort
of
what
sorts
of
surprises
do
you
think
we
might
have.
We
insights
has
had
that
a
llamó
structure
for
a
while
now
that's
been
used,
we've
proposed
some
very
specific
changes
to
it
to
allow
for
things
like
multiple
series
and
so
on
that
that
insights
doesn't
have
yet
what
sorts
of
things
do
you
think
we
might
learn
that
would
change
our
approach
to
it.
C
Yeah,
that's
a
that's
a
good
question.
I
would
say
so
from
what
I
what
I
can
get
the
first
few
charts
are
basically
something
that
are
coming
from
us
right.
We
specify
them
and
we
don't
have
to
make
a
decision
even
if
it's
invested
a
decision
right
now
to
start
implementing
GEMA
related
things
existing
in
the
repository
voting
from
the
repository
until
we
actually
made
it
and
then
believe
we
made
it
then
actually
allow
users
to
to
work
on.
B
B
What
you're
saying
you're
saying?
Look
John
Mason
in
our
first
few
applications
of
this
we're
talking
about
embedded
scenarios
in
which
users
aren't
going
to
be
able
to
modify
this,
and
we
could
just
defer
that
until
we
open
this
up
for
users,
yes
and
and
I
think
I
think
you're
right
that
we
could
get
away
with
that.
That
the
downside,
in
my
mind,
is
that.
B
We
we
aren't
thinking
about
that
specification
kind
of
all
all
along
and
then,
when
it
comes
time
to
to
open
that
up
to
users,
then
this
kind
of
a
whole
new
step
to
do
a
whole
new
piece
of
work
to
do
and
I'm
more
comfortable
with
thinking
about
the
evolution
of
that
specification
and
then
even
being
able
to
you
know,
play
with
it
and
encourage
some
others
to
play
with
it.
Even
before
it's
you
know,
fully
exposed
to
the
user,
and
so
so
I
would
prefer.
B
B
C
What
I
wanted
to
get
is
that
you
know
we
can
get
the
chat
charts
out
much
faster
when
we
don't
have
to
worry
about
the
persistence,
but
on
the
other
hand,
that
is
basic
the
same
amount
of
what
we
have
to
do
and
your
suggestion
basically
allows
other
users
we
didn't
get
them
to
play
with
this
chat.
So
I
guess
that's
a
that's.
B
We
have
teams
on
both
the
quality
org,
a
boat
in
both
equality
work
and
in
the
the
development
office
that
have
volunteered
to
dog
food.
Some
of
this,
we
won't
have
everything
they
need
to
actually
start
embedding
these
charts
in
the
handbook
right
away,
but
we
do.
We
are
they've
committed
to
working
with
us
on
a
monthly
basis
to
just
start
playing
with
this,
so
I
think
it'll
be
really
great
to
have
their
feedback.
E
So
Adam
your
yeah
I'm,
actually
curious,
so
I
think
we
agree
that
this
the
amount
of
work
we'll
end
up
doing
whether
it's
in
one
iteration
or
the
other
will
be
the
same.
Just
how
we're
approaching
it.
But
is
it
possible
to
perhaps
consider
the
the
data
types
and
structures
from
for
both
like
we
customized
abilities,
are
facing
interface
as
well
as
like
getting
it
out
faster
than
having
like
the
first
iteration
not
be
about
these
are
facing
interface?
C
B
E
C
C
B
B
B
We've
got
solution:
architects
and
services,
professionals
that
are
working
with
clients
to
meet
specific
needs
and
a
tech
savvy
consumer
base
that
can
actually
solve
problems.
You
know
faster
than
we
will
so
they
might
even
use
that
to
say.
Oh
look,
we've
got
this
data
in
in
the
monitoring
solution.
That's
telling
us!
You
know
what
our
response
rate
is
minute
by
minute,
but
we
kind
of
would
like
to
stretch
back
and
see
that
you
know
across
12
months.
Well,
the
Prometheus.
B
The
way
prometheus
is
set
up
for
gate,
lab,
isn't
really
suitable
for
that
they
need
more
long-term
storage
it.
It
would
make
sense
for
us
to
expose
an
API
that
would
allow
somebody
to
say:
okay,
I'm,
going
to
pull
this
data
out
process
it
push
it
back
in
so
that
I
can
see
this.
You
know
side
by
side
on
my
dashboard,
with
the
other
things
that
I
care
about
so
other
kinds
of
scenarios
you
might
have
around
test
results,
test
code
coverage
builds
and
so
on
over
time.
B
We'll
do
a
lot
of
that
ourselves,
but
having
an
open
API
allows
other
people
to
be
working
on
that
problem
and
making
progress
on
it
as
well,
and
there
are
awesome
cases
where
our
customer
doesn't
use
the
whole
gate
lab
suite.
Maybe
they
use
a
different
security
tool
than
is
embedded
in
our
solution.
Maybe
they
use
a
different
CI
cds
tool
that
isn't
better
than
their
solution.
C
C
B
A
John
mason,
could
you
maybe
just
kind
of
on
this
topic
of
you
know?
Jupiter
and
Zeppelin
have
been
mentioned.
Could
you
maybe
walk
us
through
kind
of
your
your
perspective
on
you
know
when
a
user
would
just
you
know,
definitely
want
to
use
those
tools
like
I,
guess
the
the
position
in
the
market
so
to
speak,
that
that
the
gitlab
charting
serves
you
know
and,
and
specifically
the
decision
to
you
know
not
not
build
something
to
sort
of
make
data
available
for
Zeppelin
or
or
Jupiter.
A
You
know
like
because
there's
really
two
directions
ago
here
right,
like
we
kind
of,
invest
in
tooling
and
say
hey,
you
should
use
one
of
these
tools
like
maybe
we
picked
you
better
and
we
say
hey.
We
think
true,
Pater's
a
great
tool.
We've
we've
built
some
kind
of
tooling,
so
you
can
pull
data
out
of
our
Postgres
database.
For
that
you
know,
could
you
talk
a
little
bit
more
about
that
side
of
things,
yeah
sure.
B
So
customers
have
asked
and
will
continue
to
ask
for
ways
of
getting
gitlab
data
out
of
the
solution.
Most
of
those
asks
are
just
for
you
know,
give
me
a
CSV
file,
sometimes
most
of
the
time
actually
customers
say
look
even
if
you
give
me
an
endpoint
with
a
CSV
file,
I
can
pull
it
at
a
regular
basis
and
automate
pushing
it
into
another
system.
If
I
need
to
you
know,
that's
that's
enough.
B
B
B
Analysis
on
what's
going
on
with
their
team,
they
would
typically
prefer
to
have
sort
of
a
dashboard
library
that
they
pull
things
together
and
they
may
need
some
help
if
they
don't
have
the
data
in
those
widgets
that
they
need.
They
may
call
to
somebody
for
some
help
to
pull
that
together.
Some
of
them
may
be
savvy
enough
to
push
some
data
in
for
a
rest
call,
but
they're
not
doing
the
the
sort
of
work
that
you
would
see
from
the
analysis
in
a
Jupiter
notebook.
That's
that's
been
my
experience
anyway.
A
B
F
Thanks
Dan
I
appreciate
the
clarification
on
how
important
it
is
to
support
configuration
and
the
MVC
when
you're
responding
to
Adams
questions.
What
I
would
love
to
better
understand
is
from
that
perspective
of
the
configuration
we'd
like
to
support
as
part
of
the
MVC.
What
do
we
have
like
a
sense
of
minimum
requirements
there,
so
I'm
I
wasn't
able
to
find
an
issue
or
a
place
that
kind
of
described
what
we
would
like
the
yamo
to
do
in
after
the
MVC
is
created.
F
That
would
allow
us
to
kind
of
test
with
some
of
these
internal
customers.
I.
Think
that
the
last
I
think
four
days
ago,
Adam
left
a
comment
about
you
know.
Do
we
have
that
example,
queries
of
what
we
would
like
to
some
of
these
queries
that
you
know
we
can
add
them
to
the
to
the
mo?
Do
we
have
anything
like
that?
What's
your
thought,
on
kind
of,
like
the
minimum
requirements
from
the
NBC
from
a
configuration
standpoint.
B
Some
sample
snippets
of
the
ya
know.
Let
me
see
if
I
can
pull
that
up.
The
idea
is
to
do
as
little
as
possible
in
terms
of
Delta
from
insights
in
this
iteration
we're
not
trying
to
add
a
lot
of
new
capability
there,
but
we
do
know
that
there
are
some
requirements
that
are
a
bit
different.
So
let
me
let
me
see
if
I
can
pull
up
the
planning
issue
and
see
if
I
can't
navigate
my
way
to
a
specific
snippet,
so.
B
F
Mean
I'll
show
you
what
I
what
I
was
able
to
find
it
was
in
this
I
was
referencing
this
generic
analytics
page
or
at
ms
recently
about
some
examples,
and
then
you
responded
with
this
and
Adam
had
another
question,
so
that
led
me
to
kind
of
believe
that
maybe
there'd
be
some
use
in
specifying
out
those
minimum
requirements
in
an
issue.
If
that
wasn't
didn't
already
exist,
but
maybe
it
already
exists.
I'm
just
know
we're
catching
up.
Oh.
B
B
B
C
Not
really
I
mean
first,
we
have
to
make
sure
that
you
know
we
can
actually
somewhat
compatible
with
the
insights
engines,
so
we
can
be
used
some
of
the
code
from
there
to
query
the
first,
the
data
for
the
first
iteration
and
later
on.
We
have
to
built
in
support
for
the
multiple
series,
the
I
guess.
B
B
E
Just
for
context,
john
mason
pinged
me
about
seeing
how
we
could
further
refine
this
issue,
so
I
sent
out
a
painting
via
comment
and
I,
wasn't
sure
if
well
I,
guess
I'm
speaking
to
Brandon,
specifically
I,
don't
know,
but
if
you've
had
time
to
review
this
issue
or
not
and
chime
in
on
whether
you
know
we're
ready
to
break
it
down
further
or
if
the
requirements
still
need
definition
or
things
like
that,
don't
want
to
put
you
on
the
spot.
So
if
it's
better
to
do
this
case,
anything
we
can
do
that.