►
From YouTube: Implementing CTAs in docs.gitlab.com – cookie discussion
Description
David O’Regan & Dallas Reedy discuss some technical details of how to implement the “Start a Trial”, “Talk to Sales”, & “Upgrade” CTAs in the docs site (docs.gitlab.com). The idea would be to pass some known information from the app (gitlab.com) to the docs site using a cookie (via OneTrust).
A
B
To
put
some
ctas
so
like
start
a
trial
would
be
a
fairly
easy
one
upgrade.
Your
account
would
be
a
more
complicated
one,
but
we'd
like
to
put
those
ctas
into
the
docs
pages.
So
we
had
some
questions
about
the
possibility
of
that
again.
Starting
a
trial
would
probably
be
fairly
easy
unless
we
wanted
to
detect.
A
B
Already
had
a
trial
going
or
already
had,
a
paid
account
and
upgrading
your
paid
account
like
from
one
tier
to
another,
might
be
more
complicated.
We'd
have
to
actually
know
who
you
were
to
send
you
to
the
right
billing
page
so
yeah
yeah.
So
that's
just
some
questions
around.
How
can
we
share
that
information
if
that's
possible
at
all?
If
that's
something
that's
changing
soon
with,
like?
Maybe
the
change
in
our
cookie
handling
system,
or
I
don't
know
some
way
that
we
can
say
like
this-
is
the
group
you
were
less
looking
at.
A
Yeah
for
anything
we
can
infer
while
on
the
sites
the
dockside
is
a
standalone
statically
generated
site
that
doesn't
it's.
It's
not
integrated
in
any
real
way,
with
the
dot
com
project,
so
adding
the
ctas,
for
you
know,
talk
to
sales
or
changing
the
url
of
the
cta,
based
on
what
page
you're
inside
the
docs
site.
That
would
all
be
fairly
straightforward.
A
B
B
B
A
Oh
well,
based
on
this
comment
here
from
laura
duggan,
it
looks
like
it'd,
be.
It
would
be
possible
because
they're
attempting
the
same
thing
with
about
gitlab.com,
so
a
script
can
be
applied
to
the
rootlevelgitlab.com
and
then
filter
to
all
sub
domains.
That
could
that
could
be
the
answer
to
our
problem.
Yeah.
A
B
A
B
A
A
A
So
I
think
then,
a
good
question,
for
I
think
a
good
question
would
be.
Is
this
something
that
we
is
one
trust
something
that
we're
implementing
on
gitlab.com
at
the
moment?
Does
this
create
a
cookie
for
a
logged
in
user?
If
it
does,
then
it
should
be
fairly
straightforward
to
access
that
cookie
on
docs.gitlab.com.
A
B
That
go
there,
so
it
seems
like
a
really
prime
place,
particularly
when
you're
looking
at
the
docs
for
feature
that
is
like
a
premium
level
or
ultimate
level
feature.
We
want
to
kind
of
highlight
that
as
well
as
you
know,
suggest
to
you,
hey
start
a
trial,
and
you
can
play
with
this
feature
right
now,
kind
of
a
thing
or,
if
you're
into
trouble,
say
hey
you
like
this
feature
like
upgrade
like
you've
been
using
this
feature,
why
not
upgrade
and
have
it
full
time.
A
Yeah
yeah,
so
it
looks
to
me
so
just
just
on
my
current
instance
of
gitlab.com.
I
have
two
things
that
come
up
is
quite
interesting.
So
the
first
one,
I'm
sorry
three
things,
so
I
have
a
visitor
id
cookie.
I
have
a
session
id
cookie
and
I
also
have
a
gitlab
canary
enabled
cookie
for
viewing
the
next
version.
Okay,
so
I
think
what
would
be
good
to
check
is.
Does
the
session
is
the
session
cookie
representative
of
a
logged
in
user?
What
is
the
visitor
id
cookie
referencing?
A
A
A
A
So
I
still
have
to
get
lab
canary
cookie,
but
I
don't
keep
the
session
cookie
or
the
visitor
cookie
okay,
so
I
think
what
we
might
want
to
do
is
in
the
same
way
we
have
set
up
the
gitlab
canary
cookie.
We
might
want
to
look
at
if
a
user
logs
in
we
might
want
to
establish
a
cookie
for
them
with
just
the
information
we
might
want
to
know
about
whether
or
not
you
know
what
plan.
A
A
Yeah,
I
think
start
a
trial
and
talk
to
sales
are
very
straightforward
because
you
don't
need
any.
You
don't
need
to
know
anything
about
the
user
ahead
of
time
to
do
that,
right,
that's
relatively
straightforward,
yeah
and
start
a
trial
is
even
I
mean
start
a
trial.
I
mean
we
already
know
ahead
of
time
when
we're
building
the
static
site,
whether
or
not
you're
self-hosted
or
this
is
docs.gitlab.com.
B
A
A
B
A
A
A
A
So
I
would
say
I'd
say:
maybe
do
it
in
I'd
say
maybe
do
it
in
two
tiers.
We
could
probably
start
with
one
merge.
That
could
add
the
cta
for
talk
to
sales
or
startup
trial,
and
then
the
second
merge
we
can
well.
The
second
merge
will
essentially
be
two
merges.
It'll
be
emerged
first,
to
get
lab.com
to
create
a
cookie
that
will
store
the
right
information
which
I'm
assuming
is
you're
gonna
need
to
know
your
tier
and
you're
gonna
need
to
know.
B
Yeah,
I
mean
it
still
kind
of
depends
on.
I
guess
what
group
you're
looking
at,
because
you
might
be
in
multiple
groups
and
one
might
be
on
a
trial,
one
might
be
paid
and
one
might
be
free,
so
that
kind
of
complicates
it
to
me.
I
don't
know
if
we
just
want
to
take
the
latest
group.
You
looked
at
as
the
one
that
we
have
the
cta
for.
A
A
B
A
B
A
In
the
same
way,
we
have
the
big
get
lab
canary
cookie.
That's
the
way
I
would
do
it.
It
would
avoid
us
having
to
add
anything
to
docs.gitlab.com,
to
try
and
get
the
user
to
verify
who
they
are.
I
mean
yeah.
No,
I
don't
think
that
makes
any
sense
as
a
long-term
goal.
I
don't
know
of
any
other
doc
site
that
I
ask
you
to
log
in
as
a
user
yeah.
B
A
I
don't
think
we're
going
to
be
taking
any
super
sensitive
information.
I
mean
it's
essentially
a
string.
I
can't
see
any
large
security
issues
with
that,
because
I
mean,
even
if
somebody
looked
at
it,
what
are
they
going
to
be
able
to
tell
that
you
were
you're
on
a
tier,
and
you
looked
at
a
group.
Is
that.
B
A
A
B
B
A
A
A
B
Okay,
that
makes
sense,
so
we
need
some
way
to
navigate
to
that
specific
group.
We
want
to
know
what
the
current
plan
tier
is,
so
we
know
what
kind
of
button
to
show
them
or,
if
they're,
on
a
trial
that
should
also
come
through
on
that
that's
good
and
then,
if
we
don't
know
any
of
that
information,
we
just
won't
render
an
upgrade
button
at
all.
We
can
still.