CSTC Template: Artificial Pageviews

Typically, your entire website (or a specific flow/wizard) is a single page application that uses history changes to modify the URL accordingly, when users transition between the different pages/steps.

Trigger

• History Change: Unless, in the rare case the website uses hash changes (identified when the URL has a hash (#) sign and the part of the URL that changes is after the hash sign).
  • Note, Custom Variables are currently unavailable with the History Change trigger.

• Trigger fires when: All pages. Unless there is a specific reason to limit it to specific URLs only, in which case you can use the “Custom” trigger condition.

URL modification

Typically, you will retain the original URL without any modification. Therefore, in the Path input field you will want to use the following syntax (copy-paste and note the curly braces):

${window.location.pathname}${window.location.hash.replace('#', '?__')}

Testing and troubleshooting guidelines

• Check your “happy path”: Follow the “happy path” on your website to ensure the APVs are firing where expected.
• Check for “double triggers”: For example, when toggling product variants on Product Description pages, or when moving to a given page such as the Checkout.
• Unexpected APVs: If you spot any unwarranted APVs getting triggered, this could be caused by a replaceState history change firing alongside the pushState one (on the website). Try modifying the URL change eventslisteners in the History Change trigger to exclude replaceState (from the dropdown) and testing again. This typically resolves it.
• Websites with Checkouts: Confirm how the APVs are triggered as you progress through the shipping, billing and other steps. Do not neglect to check what happens when you edit (go back) to previous filled out steps (i.e. are APVs getting triggered or not and so on…).
• APVs firing multiple times: If you encounter a situation where transitioning between (some) pages causes the APV to fire more than once, and you have ruled out replaceState being responsible, then you could try enabling the “Debouncing” option and adjust the timeout to be any number up to 500 milliseconds.
• Reviewing history changes on your website: If you want to see for yourself what history changes occur on your website, you can execute the following code in the console and look at the console.warn (in yellow) output in the console:

(function(){var oldpushState=window['history']['pushState'];window['history']['pushState']=function(e){console.warn('pushState detected');return oldpushState.apply(this,arguments);};var oldreplaceState=window['history']['replaceState'];window['history']['replaceState']=function(e){console.warn('replaceState detected');return oldreplaceState.apply(this,arguments);}})();

The output will be "pushState detected"  or "replaceState detected", or both. 

If the SPA does not have URL changes when you move between the pages/steps, then simply having APVs is not enough, because you'll need a way to tell them apart inside our mapping.

Custom Variables (CVAR) alternatives:

• CVARs are not available and therefore, we recommend amending the URL that gets passed to us by appending a unique value to the URL.
• This could be manual if this is a relatively limited flow, and you are creating each APV trigger individually based on some unique character of each step/page (for example, a dynamically added HTML element that does not exist on any other page/step).
• For example, you could use this syntax in the Path field (where the /step1 will be appended to the end of the actual URL): ${window.location.pathname}/step1
• If the flow in question has something on the page that denotes each step (for example, a breadcrumb widget), you may consider appending its text to the step and making it dynamic, for example (where div.step-box.active is the CSS selector that holds the breadcrumb text): ${window.location.pathname}/${document.querySelector("div.step-box.active").textContent}

Triggers:

Element Removed:

• You will need to first identify an element on the page that:
  • does not exist prior to moving to the step you want to trigger the APV for
  • gets added to it dynamically as you move to it
  • does not exist on any other step/page
• The trigger will fire multiple times for each time the element in question is added to the page (watch out for any false positive triggers when testing)
• When testing, make sure to validate the APVs are firing not only when moving up the flow but also back and forth.

Element Becomes Visible:

• This Trigger is best used for modal pop-ups where there is no actual flow and no need to re-trigger more than one (for example, this could be an ‘add to cart’ modal pop-up).
  

There are 2 items you need to configure:

• Modify the URL to tell it apart from the page it's on
• Use the most suitable trigger

This value could be manual if this is a relatively limited flow, and you are creating each APV trigger individually based on some unique character of each step/page (for example, a dynamically added HTML element that does not exist on any other page/step). For example, you could use this syntax in the Path field (where /add_to_cart will be appended to the end of the actual URL):

${window.location.pathname}/add_to_cart

While you could theoretically use almost any trigger, typically, in such a situation your option is limited to Element Becomes Visible trigger. 

• The Element Becomes Visible trigger is the ideal option in case the modal pop-up HTML already exists on the page even before it was triggered for the first time.
• However, it should be stressed that it fires only once per "natural" page view, which means that once it was triggered, it won't be triggered again on the same page view. This is not a problem for most website, except when you're dealing with SPA websites where if you've used it up once any subsequent modal triggers will NOT get triggered again, making it a very problematic choice.
• It's a good idea to also fire an APV when the modal is closed, which is where the Element Removed trigger comes in handy. All the same things apply, and since you're back on the "original" page, you do not have to modify the URL, so the following should be put into the Path:

${window.location.pathname}${window.location.hash.replace('#', '?__')}