Experiment Activation targeting

What activation targeting is

Activation targeting lets an experiment wait for a signal from your own website before it runs. The experiment stays off until your site sends an event, or until a particular element is on the page. For example, you can show a checkout test only after a visitor has actually reached checkout, or only on pages where a promotion banner exists.

It adds one more condition on top of the targeting you already have. URL, device and cookie targeting still decide where an experiment can run, and activation decides when. An experiment with no activation rules works exactly as it did before.

How the targeting types work together

A visitor sees an experiment only when every section that has rules is satisfied. Inside a section, the rules combine in different ways:

• URL targeting checks the full page address, including the query string. A trailing slash is ignored. One matching rule is enough, and with no rules the experiment runs on every page.
• Device targeting checks Desktop, Tablet or Mobile. One matching device is enough, and with no rule it runs on all devices. You can add up to three, and "All" replaces specific choices.
• Cookie targeting checks the visitor's browser cookies. The text you enter is looked for anywhere in them, not in one named cookie. One matching value is enough, and with no values every visitor qualifies.
• Activation checks for an event your site sends, or an element that is on the page. Every rule must be met, and with no rules the experiment is not held back.

Each of these sections has an info icon in the dashboard that explains the same thing.

Set it up in the dashboard

You add activation rules in the experiment's settings, next to the other targeting.

1. 1Open the experiment and go to its settings.
2. 2Find Targeting & conditions. On the left, open the Activation group.
3. 3Drag Event sent by the site or Element on the page into the target area on the right.
4. 4In the dialog that opens, enter the event name or the CSS selector, then choose Add.
5. 5The rule appears as a chip in the target area, for example Event checkout-started or Selector .promo-banner. Add more rules the same way.

To remove a rule, choose the x on its chip.

A rule is saved as soon as you add it, but it only reaches your website when the experiment is published: when you start it, or when you push changes to a running experiment. The Activation group is not available for URL Redirect experiments.

Send an event from your site

An event rule waits for your site to say that something happened. Your developer sends the event, using the same name you typed into the dashboard rule. Names are case sensitive.

Option 1: the Pertento queue. This works on any site and is safe to call before or after Pertento has loaded:

(window.PertentoQ = window.PertentoQ || []).push(['activate', 'checkout-started']);

Option 2: Google Tag Manager or the data layer. Push an event named pertento_activate and put your own name in pertento_event:

dataLayer.push({ event: 'pertento_activate', pertento_event: 'checkout-started' });

Option 3: an event you already send. Any event name that already goes into the data layer can be used directly as the rule's name. For example, a rule named begin_checkout waits for the Google Analytics 4 event of that name, with no new code.

Which one to use. If your site uses Pertento's own tracking instead of the Google Tag Manager data layer, use the Pertento queue. Data layer events that were already there when the page loaded are still picked up, but events added later are not. On every other site, any of the three works.

There is deliberately no function to call. A call made before Pertento has loaded would cause an error on your site, whereas the queue is safe at any moment.

Use an element on the page

An element rule waits until a CSS selector matches something on the page. You do not need to change your site's code for it. Some examples:

• .promo-banner matches any element with the class promo-banner.
• #checkout-form matches the element with the id checkout-form.
• [data-ready] matches any element that has a data-ready attribute.
• body.logged-in .cart-summary matches a cart summary, but only on a page where the visitor is logged in.

Pertento checks the page when it loads, and again when the page changes while it is waiting, which covers sites that render their content after load. The check is live and is never saved, so an element that is on the product page but not on the cart matches only on the product page.

To test a selector, open your browser's console on the page and run document.querySelector('.promo-banner'). It returns the element if there is a match, and null if there is not.

Two things to watch for:

• An invalid selector never matches. The experiment stays off, so check for typos.
• Do not gate on something the experiment itself replaces. If the experiment's own change replaces or removes the element its rule needs, the experiment can switch itself off the next time the page is re-checked. Choose an element that the experiment leaves in place.

How it behaves

Events are remembered. Once an event has been sent in a visitor's browser, it stays true for that browser on later visits and cannot be taken back. That suits "reached checkout" and does not suit "the cart has items", which can stop being true. Use an element rule for something that comes and goes.

Only events that a running experiment uses are kept. If no running experiment waits for an event name, it is not remembered. An event sent before the experiment that uses it started will not count.

What is stored. The event name and the time it was first sent are saved in the visitor's own browser, in local storage under the key PERTENTO_ACTIVATIONS. No personal information is involved. If the browser blocks storage, such as in some private modes, an event counts only for the page the visitor is on.

Elements are checked live. They are looked for on each page and never saved.

Visitors already in the experiment. They keep their variant, but they see its changes only where the targeting passes, including activation, exactly as with URL targeting.

Late signals apply late. If an event is sent, or an element appears, after the page is already visible, the changes apply at that moment. The visitor may briefly see the original page first. The signal does not exist earlier, so this cannot be avoided.

Adding a rule to a running experiment. Once the change is published, visitors who have not yet triggered the signal stop seeing the experiment until they do. That changes who is in the test and can affect its results, so add rules before you start the experiment whenever you can.

Limits and rules

• Event name: 1 to 64 characters, using letters, numbers, underscore, dot, colon and hyphen. Case matters.
• Element (CSS selector): 1 to 200 characters. It must be a valid CSS selector, or it never matches.
• Several rules on one experiment: every rule must be met.
• The same rule twice: not allowed. Adding it again shows an error.
• URL Redirect experiments: not available. A redirect happens the moment the page loads, so it cannot wait for a signal.

Troubleshooting

If an experiment with an activation rule does not show, work through these checks in your browser's console on the page.

1. 1Is Pertento loaded? Run Pertento.vex. It should print a version.
2. 2Did the experiment reach the page? Run Pertento.experimentData.experiments. Your experiment should be listed, with an activationTargeting entry. If the entry is missing, the experiment has not been published since the rule was added.
3. 3Did the event arrive? After your site sends it, run localStorage.getItem('PERTENTO_ACTIVATIONS'). The event name should be in the result. If you get null, the name does not match a rule in a running experiment, or the browser is blocking storage.
4. 4Does the name match exactly? Names are case sensitive, so Checkout-Started and checkout-started are different events.
5. 5Does the element exist right now? For an element rule, run document.querySelector('<your selector>') on that page. It must return an element, not null.
6. 6Do the other targeting rules match? The URL, device and cookie rules must all pass as well.

To test an event by hand without changing your site, run this in the console and the experiment should appear within a moment, without reloading:

PertentoQ.push(['activate', 'checkout-started']);

To run the test again from the start, clear the remembered events with localStorage.removeItem('PERTENTO_ACTIVATIONS'). If a check still does not explain it, contact Pertento support and include the experiment and website.

Frequently asked questions

Does this change my existing experiments? No. An experiment with no activation rules behaves exactly as it did before.

Can I add more than one rule? Yes, and every rule must be met before the experiment runs.

Does it work on single-page sites? Yes. The page is checked again whenever it changes, so an element that appears after the page loads is picked up.

What if my event is sent before Pertento has loaded? That is fine. The Pertento queue is read as soon as Pertento loads, and events already in the data layer at that moment are picked up too.

I use Google Analytics 4. Do I have to write new code? No. Use the name of an event you already send, such as begin_checkout, as the rule's name.

Is any personal information stored? No. The browser keeps only event names and the time each was first sent, in the visitor's own local storage. You choose the names, so do not put personal data in them.

Can I reset an event for a visitor? Not from the dashboard. A visitor clears their browser's site data, and for testing you can run localStorage.removeItem('PERTENTO_ACTIVATIONS') in the console.

Why can I not add activation rules to my experiment? The Activation group is not available for URL Redirect experiments.