►
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
Cool
so
Sam
and
I
are
here
today
to
talk
about
further,
defining
the
dashboards,
making
sure
that
there
is
coherent
as
possible
in
terms
of
providing
the
necessary
visualizations
widgets
pieces
of
data.
To
answer
the
different
questions
for
the
or
provide
answers
for
the
questions
we're
trying
to
to
solve
with
these
dashboards,
so
I
can
just
share
my
screen.
A
I
guess
I
can
go
in
order,
then
Sam
as
far
as
like
you
want
to
start
with
audience.
Yeah.
A
One
is
just
basically
trying
to
understand
like
who
are
the
users
of
our
application,
so
the
goal
of
the
dashboard
just
understand
more
about
our
users,
who
they
are,
how
many
of
them
are
there,
how
much
time
they're
spending
some
sessions
and
then
a
little
bit
about
like
what
defines
them
in
terms
of
browser
platform
resolution
language,
as
we
were
discussing
previously,
Sam
you're,
mentioning
like
these
two
charts
of
users
over
time
and
sessions
over
time
are
kind
of
the
key
elements
there
but
I.
A
Think
specifically,
you
know
what
we're
trying
to
figure
out
is
like
is
our
we
presented
more
information
in
the
vision,
proof
concept
and
would
that
make
sense
to
then
bring
over
into
this
version
of
the
dashboard,
specifically
for
the
purposes
of
our
internal
preview,
which
we
can
continue
to
add
more
information
or
data
points
later,
but
you
know
what
would
make
a
good
first
release
of
this
dashboard
right.
Well,.
A
A
B
I
mean-
and
it's
it's
not
something
that
we
have
to
spend
a
lot
of
time
on
just
to
point
it
out,
because
one
of
the
things
I
like
about
the
way
that
we've
approached
dashboards
is
that
it
should
be
relatively
straightforward
to
modify
and
update
these,
as
we
have
new
information,
new
widgets
and
everything
available,
so
yeah.
A
Session
durations,
like
definitely
one
of
those
that,
like
walks,
the
fun
line
between
because
sessions
is
important
about,
like
how
many
people
are
visiting
it
and
like
how
often
they're
doing
it
and
but
then
sessions
itself
can
also
like
well,
what
are
they
doing?
And
that
would
be
a
good
segue
into
like
the
behavior,
dashboard
right
and
and
theoretically
in
both
dashboards.
You
could
have
the
same
points
of
data,
because
the
two
are
interconnected:
I
mean
it's
all
about
your
users,
anyways
right,
so
right,
yeah,
ultimately,.
A
B
What
this
dashboard
needs
to
contain
understand
how
many
people
you
have
as
well
as
the
number
of
sessions
that
those
people
are
creating
over
time.
That's
sort
of
the
Baseline
of
this
is
what
my
audience
is
yeah.
Maybe
we
could
start
talking
through
the
single
stat
ones
just
to
discuss
what
each
of
those
are.
So
is
the
users
one
the
summation
of
every
day,
that's
shown
in
the
line
chart.
A
A
You
know
if
that
user's
ends
up
going
into
users.
That,
to
me,
is
the
total
amount
of
users
that
have
activity
for
the
given
time
frame
that
you
selected
so
in
this
screenshot.
Specifically,
it's
like
how
many
users
total
are
there
this
month,
and
so
the
line
chart
should
sum
up
to
that
in
terms
of
like
total
users
across
the
entire
time
frame,
all
right
so.
A
Yeah
we
should
assume
the
values
aren't
correct
if
it
was
just
division.
The
proof
of
concept,
so
I
I
think
one
thing
that
we
that
any
question
that's
important
to
discuss
as
well
is
like
so
we've
got
like
new
users
use
new
users
as
well.
One
of
the
metrics
we
were
tracking
or
potentially
being
able
to
track
with
sessions
is
being
able
to
determine
new
versus
returning
users.
So
I
think
we
can
clarify
this
to
like
I
think
this
makes
more
sense
as
like
unique
users.
B
The
question
about
unique
users
will
be-
and
this
is
a
an
issue
we
have
with
what
we
do
with
our
own
product.
Intelligence
at
gitlab
is
unique
users
like
say:
I
Sam
visited
the
page
three
days
in
a
row.
If
it's
a
simple
summation
I
the
number
would
be
three
but
unique
users
to
most
people
would
be
one
in.
B
So
we
have
to
make
that
distinction
clear
over
which,
which
one
we're
showing
I
think
there's
value
in
both
I
think
unique
users
is
probably
more
useful,
but
I
also
don't
know
if
that's
going
to
be,
if
that's
technically
difficult
or
not.
A
That's
something
worth
exploring
and
I
think
that's
why
it's
important
we're
doing
this
definition
now,
because,
as
far
as
I
understand
it
Jitsu
does
fingerprint
even
with
privacy,
but
it
definitely
does
fingerprint
privacy
mode
enabled.
So
therefore
it
still
will
keep
the
same
Anonymous
user
ID
as
long
as
it
can
so.
A
Theoretically,
that
number
should
be
as
accurate
as
possible
and
then
leaving
it
to
how
you
just
want
to
use
the
SDK
if
they
disable
privacy
mode
or
they
are,
you
know
being
or
they
are
quite
literally
associating
users
with
their
IDs,
which
we
theoretically
could.
If
we
instrumented
gitlab.com
you
know,
then
then
you
have
a
more
accurate
measure
of
that
and
ultimately
that's.
A
However,
you
define
that
single
stat
to
like
whatever
Dimension
you
pin
it
on
right
and
so
for
now
we
would
pin
that,
probably
on,
like
user
Anonymous
ID
to
start
for
the
internal
preview,
but
theoretically
a
user
can
go
in
and
say
I
literally
have
their
user
ID
so
I
want.
You
know
the
totally
unique
count
of
all
user
IDs,
which
would
give
you
your
most
accurate
figure
there
yeah
yeah,
but.
A
A
No
I
think
that
was
just
another
figure
for
the
perfect
concept,
I'm
trying
to
think
in
terms
of
new
versus
returning
sessions,
but
again
like
it's
into
sessions.
And
how
do
you
want
to
go
into
it
for
the
audience,
because
new
version
well
new
versus
returning
sessions?
What
does
that
mean
in
the
context
of
gitlab
first
time?
First
time,
visitors
but
yeah
it'd.
A
That
is
fairly
common,
like
I
was
I
was
flipping
through
competitor
applications,
and
it
is
an
interesting
metric.
They
do
plan
out
because
I
think
for
your
more
generic
applications
or,
if
you
think
of
like
you,
know,
I,
guess
more
Commerce
based
or
marketing
based
applications
which
were
not
immediately
gearing
towards
right
now,
but
even
for
product-based
applications.
You
would
be
curious
to
see
how
many
new
people
you're
bringing
in,
especially,
if
you're,
investing
in
like
advertising
marketing
right
so
then
well.
B
Because
there's
a
big
difference
between
my
audience
is
growing,
but
it's
the
same.
People
are
using
my
product
more
and
more
versus
I'm,
getting
new,
actual
New
Growth
from
new
humans
that
have
never
tried
it
before
Okay.
A
So
the
more
I
think
about
it,
the
more
it
makes
sense
and
the
more
it
makes
sense
to
track
you
know
of
these
sessions
coming
in
how
many
of
them
are
new,
they're
or
put
another
way,
there's
no
other
previous
event.
Data
on
this
Anonymous
user,
ID,
so
I
think
that's
worth
at
least
investigating
I,
don't
know
how
easy
it
would
be
to
implement
that
or
to
boil
that
down
to
a
single
step,
but
I
think
it'd
be
worth
exploring
well
and.
B
When,
if
we
do
get,
if
it
is
possible
to
do
that,
what
do
you
think
about
showing
this
as
a
ratio
rather
than
a
raw
number,
because
I
I
think
there's
not
it's
going
to
be
more
difficult
for
people
to
associate
here's
an
absolute
number,
and
is
this
a
big
number
or
a
small
number
for
my
data
set
where
you're
really
looking
more
for
the
ratio
of
hey,
you
did
this
campaign
to
launch
a
new
feature.
You
now
have
30
of
your
usage
from
new
humans
versus
10,
previously
yeah.
A
I
think
short
answer
is
I.
Think
it's
useful
I
think
it's
one
of
those
and
I.
Don't
know
that
we
have
this
built
into
the
single
stack.
It's
one
of
those
metrics
where
you
kind
of
prioritize
one
value
over
the
other
and
I,
and
to
me
yeah
that
Delta
or
whatever
that
percentage
is
more
important.
But
then
you
can
present
like
the
total
number
as
like
a
here's,
here's
how
much
of
that
makes
sense
so
like
well.
B
A
B
Let
me
pull
up
our
charting
Library.
We
talked
about
this
morning,
I
wonder
if
that's
already
built
in
to
some
of
that
I.
A
B
Yeah,
it
was
kind
of
weird
with
a
badge
or
you
could
put
units
on
it,
but
that
doesn't
look
no
I
I
know
what
you're
talking
about.
B
A
That's
what
I
was
kind
of
thing
like
it
was
supposed
to
something
like
this,
where
it's
like,
but
the
badge
doesn't
shouldn't,
be
a
thing.
I,
don't
think
like
that,
that
visual
presentation,
I,
don't
think,
is
appropriate.
Just
just
like
it's
it's
just
like
subtext
like
that's,
that's
what
we
call
them
e-charts
at
least
where
it's
just
like
here's.
Just
you
know
a
byline
that
gives
you
another
value
in
case.
You
were
curious
about
it,
but
I
don't
think
we
have.
B
A
B
Then
no
yeah.
A
That's
fine,
okay,
that's
fine!
We
can
start
with
the
percentage.
I
think
that
is
more
valuable
and
then
they
can
still
derive
the
calculation
from
that
if
they
want
to,
and
then
we
come
iterate
on
that
further
later,
on
total
number
of
sessions,
I
think,
makes
sense
yeah
sessions
because.
B
You
know
what
we
can
do
actually
that'll
help
make
this
really
crisp
is
we
can
get
this
memorialized
in
text
form
and
then
put
all
this
together
using
pivot
charts
in
Excel
to
make
it
very
clear
what
we're
asking
for
here
yeah,
because
that
way
we
can
have
an
example
of
going
directly
from
here's.
A
representative
data
set
here's
the
visualization
formatted
in
the
way
that
we
want
and
what
it
should
look
like
as
Excel
Google
Sheets,
obviously,
and
convert
it
into
our
our
formatting
yeah.
A
A
Was
yesterday,
but
that's
how
we
determined
sessions?
Yes,
because
we
need
to
be
able
to
you
know,
distinguish
30-minute
gaps
of
inactivity
between
events,
and
so
you
know
if
I
have
lunch
and
I
was
working
all
before
and
after
then
I
would
have
two
sessions
for
myself,
but
a
lot
of
people
work
differently,
that
kind
of
stuff,
so
on
average
how
much
I
think
yeah?
That's
actually
quite
interesting
like
how
much
do
people
come
back
and
then
how
much
time
are
they
spending
for
each
story
a
session?
A
Because
then
you
can
get
into
some
interesting
types
of
like
you
know,
different
license
types
or
personas
or
roles.
Even
you
know
how
much
work
do
they
do,
though.
Obviously
our
roles
are
a
bit
more
simplistic,
but
yeah.
B
A
B
Because
what
what's
going
to
be
the
goal
of
this?
This
is
to
provide
the
definitive
set
of
raw
data
and
we're
just
going
to
be
dumping.
The
test
data
here
or
do
we
want
to
have
these
tables
be
a
breakdown
of
here's.
Your
distribution
by
browser
resolution
Etc,
because
in
that
case,
table
might
not
be
the
best
way
to
actually
display
some
of
this.
B
A
Statin
table
so
I
would
agree
like
there
are
definitely
better
ways
to
represent
that,
and
then
we
would
also
want
to
think
about
limiting
it.
But
you
know
again
in
terms
of
the
context
of
like
you
know:
what
can
we
share
to
just
demonstrate
that
yeah,
you
have.
You
know
top
level
kpis
that
you
can
like
give
you
quick,
quick,
Insight,
a
little
bit
of
things.
A
You
can
get
kind
of
digging
further
and
then
type
is
kind
of
like
your
go-to
as
far
as
like
okay,
eventually,
this
will
be
something
that
you
can
customize
and
you
can
then
add
custom
attributes
and
things
like
that.
But
here,
as
far
as
our
conventional
defaults
right,
like
here's,
something
here's
some
information
about
your
users,
will
we.
A
B
B
A
What
I'm
saying
is
right,
so
we
so
assuming
we
have
tables
built
out.
We'd
still
have
to
build
tabs.
So
in
terms
of
like
what
we
could
build
immediately,
it
would
be
multiple
tables,
and
so,
if
you're
asking
to
introduce
a
third
column-
and
we
have
to
introduce
multiple
tables,
then
that
gets
very
visually
cluttered
right
got.
B
A
B
B
They
should
understand
it
because
your
table
would
be
showing
you
hey.
You
have
41
000
sessions
using
this
version
of
headless
Chrome.
You
have
58
users
using
that
same
version
of
headless
Chrome
or
you
have
34
users
of
34
sessions
using
Chrome
103,
but
you
have
34
users
using
it
as
well.
So
I
don't
think
that
would
be
confusing
to
people
viewing
the
dashboard.
B
A
B
Although
maybe
maybe
your
question,
then,
is
what
what
do
we
lose
if
we
just
get
rid
of
the
table
altogether
from
the
default
one
and
let
people
build
their
own
tables
in
their
own
dashboards.
A
A
Eventually
so
I
mean
it's
easy
to
say
like
okay,
we
only
show
browser
right
now,
but
at
some
point
you
can
choose
whatever
Dimension.
You
want
right
resolution
language
platform,
OS
the
device
whatever.
So,
if
you've
met
it
entirely,
then
we
kind
of
lose
a
little.
B
B
Yeah,
not
sure
I
just
want
to
throw
the
question
out
there
since
the
table
on
this.
This
POC
diagram
is
a
lot
more
complicated
than
the
table
on
the
behavior
one,
which
is
just
the
page
areas
single
table.
We.
A
B
A
B
Let's,
let's
keep
it
then
so
we'll
do
the
browser
browser
single
table,
we'll
punt
the
tabular
tables
until
that's
a
ux
convention.
We
support
okay.
B
Well,
so
there's
always
the
question
in
dashboards
about
when
does
it
become
too
information
Rich
to
the
point
where
it's
too
noisy,
right
and
I'm,
just
at
just
asking
the
question
of
if
we
remove
the
table,
how
much
more
or
less
valuable
is
the
dashboard
as
a
whole
afterwards,
because
I
think
we're
already
at
the
point,
if
we
add
more
widgets
we're
probably
getting
to
the
two
noisy
part,
we
were
looking
for
ways
to
simplify
the
table
so.
A
B
A
But
like
you
should
have
something
that
that
makes
sense,
but
you
know
some
of
our
group
ones
are
that
big
I
feel
like
that's
subjective
and
then
lends
itself
to
the
whole
fact
that
they're
customizable.
So
the
whole
point
of
this,
then
my
goal
of
at
the
internal
retrieve
at
least
is
just
like
to
demonstrate
what
we
can
do
so
far
with
the
dashboards.
A
Do
I
think
the
tables
are
makes
the
dashboard
as
a
whole,
too
much
sure,
but
I
think
there's
ways
you
can
arrange
it
that
you
can
like
maybe
put
these
two
columns
aside.
These
two
line,
charts
side
by
side-
and
you
know,
bring
them
a
little
bit
above
the
fold,
but
I'd
be
curious
about
what
what
my,
what
devices
or
what
like
languages
the
users
are
using,
especially
if
you're
thinking
in
terms
of.
A
Yeah,
let's,
let's
keep
the
table
then:
okay,
all
right!
So
we're
almost
a
time
but
I
think
we
covered
I'm.
Sorry
I
keep
scrolling
but
I'm
good.
Probably
if.
B
B
A
B
Right
so,
let's
talk
about
Behavior,
then,
because
this
one
we're
really
trying
to
get
to
the
point
of
that.
You
have
your
users.
This
is
talking
about
what
they're
doing,
how
they
actually
behave
and
interface
with
your
your
application
right
so
similar
to
the
previous
one.
It's
really
the
line
charts
for
me
that
are
the
critical
sort
of
things
that
have
to
be
here
in
terms
of
page
views
as
well
as
events
they're
happening
over
time.
B
A
Sorry,
apparently,.
A
This
is
my
first
time
using
this
Rich
Text
Editor
and
it's
working
well
for
the
most
part.
But
okay,
so
we
go
into
pages.
I.
Think
summation
makes
sense
here
because
it's
just
of
a
given
time
zone
or
time
time
period,
how
many
pages
so
total
pages.
A
B
A
Don't
I'm
just
what
I
want
to
do
is
just
review.
What's
been,
screenshot,
get
rid
of
these
screenshots
and
then
come
up
with
better
wireframe.
B
A
Accurate
wireframes,
so
logins
I
mean
it
would
be
cool
at
some
point
to
like
track
custom
events,
but
we're
not
looking
at
that
right
now
and
so
I.
Don't
think
that's
something
we
want
to
add.
A
B
B
A
B
Let's
take
a
little
note,
as
maybe
something
to
as
something
to
investigate
and
maybe
put
an
issue
together
if
it's
a
big
lift
but
I,
don't
think
we
need
it
for
V1
of
this
okay.
A
It
doesn't,
it
doesn't
make
so
like
we
can
do
that
for
internal
handbook,
but
we
have
to
like
create
that
because
we
don't
have
rails
Pages
like
we
do
on
gitlab.com,
and
that
to
me
is
like
that's
something
we
can
track
and
we
can
add,
but
I,
think
for
now,
and
because
we
only
have
one
table
just
for
like
the
simplification
of
it.
I
would
just
say
like
top
events
or
top
pages,
or
something
like
that.
B
Yeah
no
I
yeah,
that's
what
I
was
going
to
say
too
I
I
agree,
just
the
unique
pages
and
show
the
ones
which
are
the
most
commonly
viewed
I
think
is
useful
for
what
this
table
should
display.
Yep.
A
A
We
can
even
use
the
page
name.
Thank
you.
B
It's
past
the
slash
so
like
slash
handbook,
yeah.
B
B
I
I
don't
have
a
strong
opinion
about
this
for
our
internal
purposes.
All
of
this
should
just
say
internal
handbook
gitlab.io.
So
no
one
cares
about
that.
The
question,
I
guess,
would
be.
Are
you
using
a
single
gitlab
project
to
host
multiple
websites
that
have
unique
Ur
like
URLs,
which
saying
that
out
loud
I?
Don't
think
you
would
right.
B
A
This
is
connected
to
project
level
and
in
the
same
way,
we
use
other
products
where
it's
like.
You
know,
you
have
a
single
property
like
that's,
not
as
a
project
in
this
case,
so
I
mean
theoretically,
you
could
track
multiple
websites
with
this
and
we
technically
are
kind
of,
but
you
shouldn't
be,
at
least
in
terms
of
how
we
intended
at
the
project
level.
So,
okay,
now
rush
for
me,
cool.
B
A
I'm
sure
there
are
especially
with
regards
to
like
the
table,
but
you
know
going
on
just
a
simple
one:
table
set
a
single
stats.
I
think
that's
enough
to
go
on
for
now:
I,
don't
I,
don't
think
we
have
to
like
I
think
what
we
have
is
plenty
is
what
I'm
trying
to
say.
How
do
you
feel.
B
It
okay
cool!
Well,
let's,
let's,
let's
move
forward
with
this
one,
okay,
so
I
think
in
terms
of
next
steps.
I
will
go
ahead
and
try
and
create
a
pivot
chart
version
of
each
of
these.
If
that's
helpful,
upload
those
as
a
design
file,
yeah
yeah,
so
that
that
can
be
used,
and
then
we
can
mark
the
vision,
pocs
screenshots
as
deprecated
yeah,
and
use
the
requirement
lists
above
and
said
going
forward.
A
For
sure
I
think
this.
This
was
very
useful
in
terms
of
a
getting
a
little
bit
more
specific
about
what
we're
expecting
to
see
on
the
dashboards
into
the
next
Milestone.
So
awesome,
then
I
will
edit
this
recording
to
I
didn't
realize.
I
was
going
to
show
my
terminal
because
I
selected
a
specific
window,
but
I
will
edit
that
out
and
then
upload
it.
A
B
And
so
yeah
I
think
it
ended
up
in
a
good
spot.
Yeah.
A
So
we'll
we'll
Samuel
work
on
the
kind
of
pivot
table
version
of
that
we'll
deprecate
these
these
proof
of
concept
screenshots
and
then
we'll
review
it
with
the
team.
Next
week
sounds
good
awesome,
Sam
I
will
catch
you
later.
Then.
B
All
right
we
will,
we
will
talk
soon,
I'm
sure
again,
all
right,
yeah
all
right
see
you
later.