Ability to remove visitor from experiment results / Targeting based on DOM

Status: Maybe One Day
by welshmike ‎06-19-2014 June 19, 2014

It would be great if there was an 'exclude from reporting results' type call that we can add within the advanced variation code.


Essentially, I wanted to create an experiment for our Product pages where only a subset of the pages contained the document element that I wanted to modify. I would like to say if element does not exist, exclude this pageview from the reporting.


Full history of the request can be found here http://community.optimizely.com/t5/Developers/Track-results-only-when-element-exists/m-p/2226#M62


Status: Maybe One Day
Level 2

‎06-20-2014 June 20, 2014

I am 99% certain that this change would be welcomed by all Optimizley users.


The sooner you can get it in the better from my point of view.

Level 11
‎06-20-2014 June 20, 2014

Hear hear, would love to see this as well. It's pretty annoying that I have to check for the specific DOM elements in a test to run it while it still costs me views.

Level 10
by Aicke
‎06-25-2014 June 25, 2014 - edited ‎06-25-2014 June 25, 2014

I still don't understand whats so difficult to use the already build in javascript targeting, via "Options -> Targeting -> Satisfy this custom Javascript condition". Tell me if I'm wrong.


You don't have to change anything for that on your page! And I've already used that for an experiment where an AD was visible only on a small amount of our pages.


The following line (taken from the original request), should trigger the experiment on these pages only.

$('#input1 option').size() === 1 && $('#input1 option').first().text() === 'One Size'


For more information take a look here: https://help.optimizely.com/hc/en-us/articles/201876450-Use-cases-for-Audiences#use_case6

Level 2
‎07-02-2014 July 2, 2014


I'm familiar with the use of javascript targeting (we use it to insure that our experiments run exclusively) but I was curious about the specific use case you wanted us to see in your link.


Do you have a real-world example where this has worked for you?


Why I believe this wouldn't work:


Based on what I can glean from the article you posted, the examples consistently depend on HTML or browser elements that are accessible at the time the targeting code runs. For instance: In the example in which targeting is directed only to visitors who are logged in, the code that sets this flag is shown to exist on the page immediately before the instance of the Optimizely snippet.


There is a profound "Chicken and the Egg" dilemma inherent in attempting to use javascript targeting based on the existence of DOM elements. The targeting conditions determine "Is this visit valid for the experiment". Only after that determination is made (and answered "yes") can the variation application begin. It's like saying "I'm not going to decide to read this book until I've read it and know what's in it!" 


A clean test of variations on a user experience depends on the ability to modify the DOM in that mystical moment between loading the DOM (DOM Ready) and the rendering of the page. Otherwise, a page would fully render as it was originally written, then apply the variation changes in full view of the user.




In order for a variation to work without disrupting the page load experience, the targeting evaluation code must run before the DOM is loaded.

For more information: https://help.optimizely.com/hc/en-us/articles/200040335

To address the original post


It sounds like this request is for an "Undo" call in the API. That's a very interesting idea. 


An alternative might be to introduce 2-stage targeting. 


Optimizely could default to single stage targeting. The optional second stage could be as simple as a checkbox setting that would essentially say,

"Hey, Optimizely! In case you didn't notice, the variation code didn't run because the jQuery selector turned up nothing. What do you say we back this one out?"

For a little more flexibility, there could be an optional second condition type that allows the entry of a selector the same way a click Goal is created.


I've used another testing product that did this as "HTML Conditions". This was easier to achieve in that product because it handled variations before the page gets to the browser so it didn't rely on client-side javascript.


Backing out once the view has been activated and assigned is a much more complicated task.


Level 7
by Aicke
‎07-03-2014 July 3, 2014

Because this stupid Optimizely form killed my whole answer (authentication error while I'm still logged in), I had the chance to improve my answer Smiley Happy


1. There is no "mystical moment", the dom will be rendered/painted not at once:

It's important to understand that this is a gradual process. For better user experience, the rendering engine will try to display contents on the screen as soon as possible. It will not wait until all HTML is parsed before starting to build and layout the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the contents that keeps coming from the network. (http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Rendering_engines)

2. The javascript targeting condition is checked (afaik) repeating every 50ms from the start of the optimizely script until domready, not only once. That means it will wait until the condition is true, otherwise it will not start the experiment at all.


3. For your book example this would mean, the user reads the book until a specific page and "we" decide in 50ms (e.g. there is a special word in the first or second or third line of that page) if we want to remove that page (or a later one) for the user or not. There is virtual no delay, if you don't believe that, try it out first and give feedback then.


4. The only drawback I can imagine is, that you check for a later element in the dom and want to remove one element which already is painted on the screen (e.g. the user is on page 100 and you want to remove page 2). Then you may modify your targeting condition or use optimizely tags (https://help.optimizely.com/hc/en-us/articles/201876450#custom_tags)


Tell me if I'm wrong, I'm pleased if I learn something new.

Level 2
by Optimizely
‎11-10-2014 November 10, 2014
Status changed to: Maybe One Day