Rich-text Reply

[workaround] testing new vs. returning for ad campaign (non-enterprise)

charles 11-18-14

[workaround] testing new vs. returning for ad campaign (non-enterprise)

[ Edited ]

just started testing this workaournd" and looking for some feedback. 



- our SEM/PPC campaigns benefit people who are mostly in the later stages of the buying cycle (e.g. ready for a free trial, or to purchase)

- to help people get started right away we send them to a landing page with a signup form (and not much else)

- however, sometimes people will click on an ad, bounce, then click on antoher ad, bounce, etc.

- if we assume some people who exhibit this kind of behavior are in the earlier stages of the buying cycle, and would prefer white papers and case studies to free trials, then that's what we'd like to give them


brief overview of setup:

- create optimizely experiment with a redirect variation for an SEM/PPC landing page

- create optimizely audience with a cookie condition, and configure so that visitors in that audience see the experiment

- cookie visitor's browser after the landing page loads (lots of ways to do this) [1]

notethis works for us because we send SEM/PPC clcks to dedicated landing pages (which aren't indexed, or linked to from anywhere else), and we use optimizely's URL targeting.


next steps are to test redirects to differently themed landing pages for SEM/PPC visitors (i.e. to generate marketing leads where signups might've failed), and to develop best practices around measuring the results. 


related note: something we haven't tested, but are looking into, is parsing URL parameters to set the audience. this could allow us to create ads for different campaigns that link to the same signup landing page (where we may serve different variations of the same LP), but redirect return visits to any number of different info-themed pages (where they could download/access content relevant to their specific campaign/vertical). 


if anyone else has tried this, or has feedback, feel free to share.


[1] here's some code we used in the test to set/read cookies

function createCookie (name, value, days) {
    var expires;

    if (days) {
        var date = new Date();
        date.setTime(date.getTime() + (days * 24 * 60 * 60 * 1000));
        expires = "; expires=" + date.toGMTString();
    } else {
        expires = "";
    document.cookie = escape(name) + "=" + escape(value) + expires + "; path=/";

function readCookie (name) {
    var nameEQ = escape(name) + "=";
    var ca = document.cookie.split(';');
    for (var i = 0; i < ca.length; i++) {
        var c = ca[i];
        while (c.charAt(0) === ' ') c = c.substring(1, c.length);
        if (c.indexOf(nameEQ) === 0) return unescape(c.substring(nameEQ.length, c.length));
    return null;

var czCookieExists = readCookie("czWelcomeVisitor");

if (!czCookieExists) {
  createCookie("czWelcomeVisitor", 1, 90)


Level 2

Brian_Abad 11-18-14

Re: [workaround] testing new vs. returning for ad campaign (non-enterprise)

Thanks for submitting your idea, Charles!


I'd like to further understand the type of experiment that you're looking to set up. From what I gathered from your message, you'd like to set up an experiment for first time visitors coming from a specific ad campaign, utilizing the Optimizely experiment to drop a cookie onto the user's browsers, then set-up a separate experiment that targets this cookie in order for a user to be bucketed into this separate experiment - is this correct?


In the mean time, one thing that I wanted to highlight within the suggested experiment set-up is that in a redirect experiment you are not able to make changes to the redirected page - or in this case, this experiment will not be able to drop the cookie on your redirected page. What's happening is if a user lands on an experiment's targeted URL and fits the Audience visitor conditions, traffic allocation then determines which variation to serve. If they end up in the redirect variation, the redirect code is ran on the original landing page URL and the user is now redirected to the new page. At this point, no other code to render changes (or drop the cookie in this case) can be ran on the redirected page via this particular experiment. Does this make sense so far? 


A workaround for creating changes on a redirect URL (or in this specific case, drop a cookie on the redirect URL), is to set-up a separate experiment, with the separate experiment targeted to the redirect URL, and utilizing this separate experiment for the sole purpose of creating changes (once again, dropping your cookie) onto users who are redirected from your original experiment. In the separate experiment, I would suggest setting Traffic Allocation to 100% of the variation in which you are making changes (dropping the cookie). That way, when users are redirected from the original experiment, they will all be served the variation of the separate experiment in which these changes are made (a cookie is dropped).


I wanted to scope my response out to be more general with how to run code on a redirected page without access to Multi-Page experiments, while referencing your cookie dropping code in parathesis to also be specific to your message.


All that being said, I'm happy to continue this discussion on the type of experiment you're looking to set up for new and returning visitors for your ad campaigns. Just wanted to first touch base on what's occurring within the redirect experiment Smiley Happy

Brian Abad
Manager, Technical Support
Customer Success
charles 11-18-14

Re: [workaround] testing new vs. returning for ad campaign (non-enterprise)

@Brian_Abad , thanks for your comments.


fortunately none of those limitations seem to apply to our setup.


we drop the cookie outside of optimizely. in optimizely we've created an audience that reads the value of that cookie, and an experiment for that audience.

Level 2