Tech & Development Archives |

Introducing:’s Optimizely Chrome Extension

Today we are very excited to announce the public launch of our Optimizely Chrome Extension. We’ve been using the extension internally and been improving the functionality over the past year.

We began rolling it out to our clients over the last few months, and after some great feedback we decided to put it into private beta last month. Today, we are thrilled to share it with everyone!

Solving problems you never knew you had.

We feel like’s Optimizely Chrome Extension is one of those wonderful tools that you never knew you needed – until you start using it. And now that we’ve started, we couldn’t live without it.


What does the extension do?

The feature list is impressive and always growing. At the time of launch, the core features we want to highlight are below. Here are 8 great reasons you should install the extension today.

  • Quickly see whether Optimizely is running on the page (if the circle turns blue, Optimizely has been detected on the page)

Icons x and 0

  • See how many experiments are running on the page (that’s the white number within the blue circle)

Icon 3

  • Toggle between QA mode to see your experiments and variations that are not yet live with the flick of a switch*

optimizely extension QA

*Be sure to set up the QA cookie first – only users with the QA cookie set-up will be able to see tests in QA mode.

  • Switch variations quickly within an experiment with the handy drop-down selector. This will reload the page and bucket you into whichever variation you have selected.


  • Jump straight into the Results and Editor pages of any experiment. Just make sure you’re logged into your Optimizely account!


  • Copy an experiment URL to the clipboard – this way you can be sure that you and your colleagues are looking at the same thing!

Copy Url

  • Thought the QR code was dead? Wrong! We finally found a great use for the QR code. Snap a picture of the QR code to see the same experiment and variation quickly on your mobile device.

  • Finally, make sure you are tracking the right events with the events console. This will show you Optimizely tracking, segmentation info and manual activation info.


Check out the FAQ for the full feature list and more detail!

Once you’ve installed it, be sure to take it out for a spin.

We’d suggest the following activities as a great way to get started and set you up for success:

  • Read the FAQ
  • Set up a QA cookie, to make the best use of QA mode and to check out your experiments before they go live!
  • Visit a page you’re running a test on, and check out all the experiments and variations with one handy interface

Before you start using the extension please be sure to review Optimizely’s best practices, and be sure to mask descriptive names of your tests.

Send us your feedback!

We hope you’ll find this new tool as useful as we have. If you want to send us feature requests, report bugs, or tell our Optimizely Certified Development team just how much you appreciate them, please use the handy little “Get in touch” button on the extension.

What are you waiting for?

Click here to get your hands on the extension and start saving time!

Specialist teams or x-functional pods? A developer’s view is an agency comprised of specialists that will look for opportunities to improve client’s ROI through methodical research, testing and learning.  We analyze user behaviour and expectations of a website, in order to increase engagement levels and consequently, conversions.

Testing is at the heart of everything we do, so we’re always trying to improve and find better ways of doing things. Typically, our company is split into three major ’specialist teams’ – consultants, designers and developers.

Consultants: Their role is to perform in-depth research of a client’s website and get relevant insights about the business. Consequently, test ideas are generated and wireframes created. Also they are the main bridge between our clients and internal teams.

Designers: They feed into the wireframe stage by collaborating on ideas on how to implement the test concept. After approval on this stage they elaborate the final design file that will be transferred to the developers.

Developers: These geeks have the ability to transform the final design file into code readable by browsers. This is the final stage of the test creation flow.

After this internal process the test runs to a live audience through an A/B testing system, where at the end consultants analyse the final results and make recommendations for the client’s site.

Here is how the teams typically interact within the company:

As can be seen, developers come in at the very end of the process.  After designers have completed the final file they assign to one of the developers available at that moment. This is great from a developer’s standpoint, because they have the opportunity to work on many different clients and retain a good working knowledge across all of them. However the downside to this is that the work overload can be an issue. This happens because different consultants have different deadlines to deliver tests, so at times, congestion becomes unavoidable. Sometimes many tests come in to the development team simultaneously, and it is difficult to manage requests in order to deliver each test at the desired time.

Because of these issues, we had an idea to grab an element of each team and make them work more closely together. We have created a cross functional team a.k.a. pod.

What exactly is a pod?

A pod is like a small startup inside the company. Instead of organizing your business in separate functional departments, you create teams that contain a member of each function. Let’s illustrate what we have done within our company:

Graph 2

Clear goals and collaboration

With the team working collectively on the same clients, it’s much easier to sync up schedules. Since we always have a priority list for our tasks the team will work towards those goals by order. For example if a developer needs designer approval for a certain test, the designer will stop whatever they are doing to evaluate the developer’s work because that is the current priority for the whole team.

 Tidy schedule

Because there are clear goals, the project manager is able to build a clear schedule for everyone in the team. This helps the developer to know what work is coming soon to his stack. In this way, the developer can manage his time, along with his other number of tasks. This allows the developer to shift his projects the way he prefers as soon as he delivers his work on the expected deadlines.

Earlier technical evaluation

We have introduced a new format for the test idea/concept phase. Before the pod, the developer had little input at this stage. The developer is now an active member of the conceptual phase, bringing valuable know-how on potential implementation issues. Sometimes even a very slight different approach can save many hours of development and help the team deliver a certain test faster (for example – implementing native placeholders can cause cross browser compatibility problems. The developer might ask at this stage ‘is this really required for the test? Will this make a significant difference to conversions?’) Also, assimilating with the test at the very beginning can be good for the developer to research and develop some code practices that will be required to implement it (e.g. get familiar with new frameworks).

Faster test development

Since the developer has a clear pipeline he can start to develop the test before he actually receives the final design file from the designer. How is this possible? Well, before the designers start to work on the final photoshop file, there is a wireframe stage. As soon as we get approval from the client on the wireframe the developer can start to work at the same time as the designer prepares the final file. This is possible because the wireframe gives a clear indication of what the test is all about. With this visual info the developer is able to develop a big chunk of the HTML, CSS and javascript. Remember that from the test idea phase the developer already knows what functionality and goals the test is supposed to deliver. This allows the developer to finish around 70-80% of his work even before the designer delivers the file. With the final file developer just needs to make some tweaks on the code (e.g spacing, colours, etc.). So far, this new process has allowed us to deliver tests 35% faster than before.

Quick decision-making

Because the members are simply around each other, as opposed to working in silos, it is easier to take a minute to discuss something momentarily. Moreover, interrupting one of your team does not feel so intrusive because if you need something to finish the pod’s priority task, they are more open to being interrupted in order to collectively help meet the team’s goals.


Because the pod is like a small startup within the company, it allows the team to change processes and try new ways of working. This can be very useful in finding more efficient ways of working which we can then share with the other pods.


As optimizers, a testing culture is a vital part of how we work. This means we also need to measure everything and be able to critically evaluate how things are doing. Here are the results we have observed so far by moving from a specialist-teams to cross-functional pod approach:

  • 35% faster test delivery time from start to finish  By developing test ideas in parallel, as opposed to serially, we have seen a significant reduction in the total time lapsed from the inception of a test to the final launch.
  • 28% reduction in actual developer build time  By integrating the developer more closely in the design and consulting phases, devs have a much better idea of how to go about building the test at the point they start working on it, meaning the build time is dramatically reduced.
  • 66% reduction in bugs reported during QA  Consequently, developers are able to build tests more intelligently by anticipating any issues, and feeding in to the test development earlier on to avoid prospective clashes.
  • Happier team members  Although there are a few downsides to working in the pod, such as less variety of sites we get to work on, the individual members of the pod are generally much happier with this new approach, because they are working as a team throughout the whole process. This means fewer internal conflicts and more efficient workflows.
  • More time to work on other projects  Because we have increased efficiency across the board, pod members have more time to spend working on other tasks, such as internal assignments and creative projects. The introduction of a project manager also means that consultants spend more time doing valuable conversion-related work and less admin, which is likely to be correlated with the uplift in team happiness!

While it is still early days for the pod, the initial results and general consensus are a positive indication. As a developer, there are far fewer conflicts and less back-and-forth between the design and consulting teams, and we have become much more connected to the conversion aspect of what we do. The developer becomes more of an expert on a smaller number of clients’ sites (as opposed to a generalist working across the whole spectrum). Despite the small downsides – for example, if a pod developer is needed to work on a different client’s site they may initially be less familiar with the technical setup of the site; the surplus time the developer has as a result of working in the pod can be used for more internal sharing and learning which may be more valuable in the long term. The developer also has to adapt to many more meetings than they are typically used to (!) however the benefits of being more involved in the project overall makes it worth our while.

Do you have anything to add? Questions or comments? Let us know in the comments below!



Introducing our fully Optimizely certified developer team

We are proud to announce that the entire development team are Optimizely certified developers!

Our savvy dev team have been working closely with Optimizely since October 2013 and the entire team are now Optimizely Developer Certified. We’ve really gotten to know Optimizely over the years and we’re co-creating more innovative solutions all the time (so watch this space!)

Be sure to check out our must-know 6 essential tips for working with Optimizely from our very own James Marchant (second-left in the picture).
Stay tuned for more updates!

6 Essential tips for any developer using Optimizely

Developing within Optimizely is a unique undertaking that has few parallels with conventional front end development. In this post I will outline six gems of knowledge that I have gained while building tests in Optimizely for a wide range of clients. Please note: this post assumes that you have knowledge of writing code within Optimizely.

1. The Optimizely log is your best friend

My first essential tip is the use of the invaluable Optimizely log. The log contains all the information on bucketing, segmentation, audiences and code execution on your site on page load while also displaying execution times of each part in the process (for further documentation on the log, see this Optimizely knowledge base article).

To access the log, you simply type the following into the console of your page:


this will then return something like so:


This is extremely useful to locate any code that is preventing the rest of your test(s) from running that in-turn will increase flicker for the user. As all code must be written in the Identifier/Action format (see this useful knowledge base article from Optimizely on how code is executed within tests), it can be easy to forget to add non-optimised code in your experiment. Here is an example of code being delayed because it doesn’t follow the correct format:


The code highlighted is a simple variable declaration which unfortunately does not follow the correct format. You can also see, on the lines preceding, that Optimizely is continually waiting for the document to be ready in order to execute the code (our example shows it took 617ms from encountering the code to the document becoming ready, however on slower sites this can take much longer).

You will inadvertently run into this when writing tests, and it is useful to use this tool to check that all of your code is compliant in order to reduce any possible flicker for the user.

2. Use custom jQuery functions in order to add non-compliant code

There will be times when you need to add code that won’t be in the right format and there’s no way you can transform it. When this issue arises, you can simply create your very own custom jQuery functions in order to bypass it. To do so, you will need to first define your custom function within the Optimizely force parameters (see this knowledge base article on force parameters) and then reference the defined function in your code, e.g.:

/* _optimizely_evaluate=force */
$.fn.customFunction = function() {
    var number = 10;
    for (var i = 0; i < 10; i++) {
/* _optimizely_evaluate=safe */

In this example, we have defined a function originally named ‘customFunction’ which increments a number ten times before appending it to the subject when called. The ‘customFunction’ is then called on the element(s) with the class ‘main’.

The potential applications of this method are large, with other examples ranging from timeouts to loading external scripts. Another benefit for this is that the function needs to be called using a selector that is run within the Optimizely code engine, this can be then utilised in order to check for when that specific element is available to modify/change.

3. Use ‘onmousedown’ events for AJAX loaded buttons & outbound links to track goals inside Optimizely

Most Optimizely tracking goals can be added via the “Create Goal” window within the editor, however there may be times when you need to use custom events in order to record clicks on buttons & links.

When a click goal is added within the editor, Optimizely adds an ‘onmousedown’ event (see Optimizely’s knowledge base article on click goals) to the specified element and this is attached after all variation code has been run. The reason for this is so that it can more accurately track elements that may send the user away from the page.

In cases where you want to track an element that may be pulled in via AJAX or you want to manually track outbound links, then you can use the same event listener on those elements. For example, if you wanted to track a link that goes to an external page, you could do something like this:

$('.link').mousedown(function(event) {
    window.optimizely.push(["trackEvent", "eventName"]);

If the element you want to track is loaded via AJAX (or it loads later after page load), then this method poses a problem as Optimizely will continually poll the page until document ready, at which point it will execute the code regardless of whether the element is there or not. To get around this, you can use the .live() jQuery function (this is currently deprecated in all new versions of jQuery and replaced with ‘on’, however Optimizely uses the older 1.6.4 version that has this available) within the Optimizely force parameters like so:

/* _optimizely_evaluate=force */
$('.link').live('mousedown', function(event) {
    window.optimizely.push(["trackEvent", "eventName"]);
/* _optimizely_evaluate=safe */

This code will then execute on all elements with class ‘link’, regardless of when they get loaded onto the page.

4. Use the force variation parameters to bypass audience and targeting settings

When developing a test, you will want to check your code in as close to the environment that a user might see as possible. While the visual editor and the preview modes are convenient to use, they do directly modify the page in a way that could potentially affect the test and you are of course not seeing it in the same environment that the user will see it in. Fortunately, Optimizely allows you to force tests to appear regardless of their audience and targeting settings.

Firstly, you will need to make sure your Optimizely project allows you to use the force variation parameters. To check this, simply go to Settings->Privacy within the dashboard and make sure “Disable the force variation parameter” is unchecked. If it is checked, just uncheck it and hit “Save”.


Once that setting has been updated, you can then go to your site and add the following URL parameter:


Just replace “EXPERIMENT ID” with the ID of your experiment (you can find this in the editor URL for your experiment under the parameter “experiment_id”) and “VARIATION INDEX” (this is a zero based index where 0=Control, 1=Variation #1, etc.) so that it looks something like this:

If your test is a multivariate test however, then you will need to use a slightly different syntax:


As you can see, you separate each section variation with an underscore, where

will show variation 1 of section 1, the control of section 2 and variation 1 of section 3 of your test.

Always remember that this method doesn’t check for whether your test will run under certain conditions, and should only be used to check if your code works. For more information on force variation parameters, check out Optimizely’s knowledge base article on them.

5. Check the revision of the Optimizely snippet to ensure you are seeing your latest code

To ensure speed and reliability, the Optimizely snippet is loaded using Akamai that, like all other CDNs, will evaluate the best server on their distributed network to serve the code with (generally this is the closest geographically). This however comes at a price of increased save times due to the nature of invalidating files on CDNs. I’m sure many of you have had to wait minutes for your code to update, and while there is no way to improve the speed of this, you can check if the code you see on the site is the latest code that was last saved using the editor.

Whenever you save a test in Optimizely, the console displays the next revision number that it is saving to and repeats this until it has fully invalidated to the CDN.


The first line that is highlighted displays the previous revision (“12”) along with the new revision (“13”) and the number of times it has been attempted (in this case it only attempted it once but this has been known to go over 100 if the Optimizely platform is under large load). The second line shows that it has completed updating the CDN to correct revision. Edit: As noted by Toby Urff from Optimizely, the editor also shows when the snippet is up-to-date by showing “(Uploading to CDN)” next to the “Save” button while it saves and then is hidden once the revision number of the snippet matches the revision number of that save.



Once you have the test saved, you can go to your page and check the current revision by entering the following into the console:


This will return the revision number that you are currently in


This, combined with checking the log, is incredibly useful for debugging and checking your code is running correctly and you are seeing the latest version. This should also speed up your development time as you know exactly when the code has been updated.

6. Use the page’s jQuery to access more functions

As I stated above, Optimizely provides a reduced snippet of 1.6.4 that doesn’t have some commonly used functions such as .hide(), .ajax(), .getScript(), etc. This can provide a problem when attempting to build larger more complex tests that may require external APIs/scripts. There are a few solutions to this: either load the full version of jQuery via Optimizely or not to load jQuery at all and use the page’s version.

Loading the full version via Optimizely can be a quick solution, but at the same time you are significantly increasing the snippet size. It also becomes redundant if you already have jQuery on the page. On the other hand, while using the page’s version of jQuery may seem at first to be a better option in terms of overall file size, it can actually be slower if you are loading jQuery at the end of the page (as it is generally recommended that you should do).

A middle ground to these two options is to include the reduced snippet with Optimizely, but use the website’s version to access functions such as .ajax(). To do this, you will need to write a function within Optimizely’s force parameters to check the existence of the page’s jQuery and then execute your script. This could look something like this:

/* _optimizely_evaluate=force */
function checkjQuery() {
    if (typeof window.$ !== "undefined") {
            url: '/path/to/file',
            type: 'POST',
            data: {param1: 'value1'},
        }).done(function() {
    } else {
        setTimeout(checkjQuery, 50);
/* _optimizely_evaluate=safe */

Here you can see that we are accessing the website’s version of jQuery using window.$ and making sure it is not ‘undefined’. We are then accessing the .ajax() function via the window.$ scope to access a fictional file called ‘/path/to/file’. This code should load as soon as jQuery is available on the page. One thing to be aware of when using this method: if you are adding or changing content in an element that you create outside of the force parameters, then you must check for the existence of that as well as the page’s jQuery. This is because there is a possibility of the page’s jQuery loading faster than Optimizely can get to the line of code that creates the new element.

In conclusion

These tips have been slowly accrued while I have been working on the Optimizely platform over two years as a developer for These have proven invaluable to me and I hope they bring the same benefit to you as well.

Did you find anything useful in here? Do you have essential tips for coding in Optimizely that haven’t been mentioned? Get in touch with us in the comments and let us know your thoughts!