Overview
Journeys and Audits are great tools to validate marketing and analytics data. ObservePoint's ClickAll+ Solution expands the capabilities of Journeys and Audits by giving users the option to click all elements on a page and perform other types of interactions.
One of the challenges of other solutions intended to click on all links and test them is being able to associate these interactions with specific standards. ClickAll+ addresses this problem and makes wide-scale validation possible.
Implementation
This solution takes some setup, but this guide and our team are here to help.
The code below is the current version. Run it in an Audit Execute on-page action to interact with all matching elements on a set of pages.
Steps for implementation are provided below:
Note: The only portion of the code that you need to edit/configure is between the block of comments labeled USER CONFIGURATION.
2. Within the code, there is a section of code between comment blocks that is labeled USER CONFIGURATION - this is the area where you should make changes to INTERACTION_TYPES array of objects need configuration as it follows:
Required attributes:
selector
- This is a CSS selector that will return an array of all elements that match that CSS across the pages where this will run
- The best way to get this CSS Selector and determine the elements that will be interacted with is to go to a page you intend to perform this solution on and open DevTools (F12 or right-clicking and clicking “Inspect”)
- Once there, you can see tabs for “elements” and “console”
- Elements are the list of elements on the document and ultimately the way to see the best selectors for the next step.
- The console will allow you to run a small piece of JavaScript to help you know which elements you are going to have interacted with
- That small piece of JavaScript is well documented in this help document
- The array of elements that returns from doing a “document.querySelectorAll()” with your CSS selector is ultimately what will be interacted with. That CSS selector you pass into querySelectorAll will be what you give to the selector attribute of this object
targetedElementsType: This is simply a label to identify within the code and later in the results of the Audit the “category” or “type” of thing that was interacted with (e.g. download links, header links, external links, etc. This value must have no spaces
Not Required/Optional Attributes:
limitInteractions: This allows you to specify the max number of configured elements you’d like to interact with. (e.g. a page has 10 CTA buttons, but I only need to validate one of them, you’d put a 1; if I want to test all 10, put Infinity - with the first letter capitalized - as the value or just remove the attribute entirely from the object.).
Note: For situations where this is not relevant, you can leave the attribute -1 or remove the attribute entirely from the object.
elementAttributeData: For some technologies you might be testing, there may be a desire to pull in attributes and their corresponding values to validate later with the results of the Audit. (e.g. data-gtm). This is usually seen in those using Google Analytics validation, but can be used for any suite of technologies/data layers
- This value is a comma separated value
- Simply put the name of the attributes you’d like to validate in this field
- The results once the Audit runs will show up in a “data layer” tag called interactionValidation.
- If that attribute is not available in the element that was interacted with, the solution will pass a value of DATA ELEMENT MISSING to that, meaning that the element that was interacted with didn’t have that attribute.
Note: For situations where this is not relevant, you can leave the attribute an empty string or remove the attribute entirely from the object.
action: When you want to perform small "actions" that are not just clicking on selected elements, you can put a function, whose argument is the element in question, to interact with the intended elements on the page. (e.g. I want to click on a header link in order to see a link to a sub-header; or I want to add a quantity before hitting an add-to-cart button.)
Note: For situations where this is not relevant, you can remove the attribute entirely from the object; doing so will default to a “click” event on all specified elements.
3. Add the ClickAll+ data layers to your account:
In the left-hand navigation, click Configurations, then select Data Layers.
Click Add, enter
interactionObject, and save.Click Add again, enter
interactionValidation, and save.
Note: You only need to do this once per account. Data layers apply to every Audit and Journey in the account, so if interactionObject and interactionValidation are already listed, skip to Step 4.
4. Now is the time to build your Audit and apply the code you’ve configured above;
5. In the ObservePoint app, you can now create a new Audit with the following settings:
On the first tab, name your Audit and put it in a folder/subfolder appropriately;
Paste all URLs you’d like this solution applied to;
Put a limit that you’d like to have for this. The solution will interact with all elements it finds up to that limit (to prevent excessive usage);
Go to the URL Sources tab;
You will see a section for “WHICH SECTIONS OF THE WEBSITE SHOULD BE INCLUDED?"
If you’ve pasted the URLs you want tested, you should see an include list with regex statements around them, and in this section you MUST append
.*opClickAllData.*to all include list items.
5. Take the code you’ve configured above, with your USER CONFIGURATION completed, create a new Execute JavaScript on-page action, and paste it in.
6. Select Prevent Navigation in the top right corner of the on-page action. The only exception to this instruction is when a page load is required to fire the analytics call that you are testing.
8. You can now run the Audit.
Audit Results
1. Once the Audit has completed, you can now view results of all interaction actions: Each page is a pageview as well as an interaction action of each element configured in the implementation steps, on each page specified in the Starting URLs of the Audit.
2. In order to view your segments, you can search the initial URL for the linkTypes you configured in the previous step OR you can look at specific pages by filtering for just the final URL search in the Audit putting in the specific URL you’d like to see.
3. The Audit will contain the pages that “collected” the interaction elements as well as the interaction pages (Example: if the Audit ran on 10 pages and the Audit resulted in 500 pages, the Audit has 490 “interaction” pages, like a link click, for example). You can filter for these pages by simply filtering URLs for “opClickAllData”
Note: It is strongly advised that in the configuration steps above, you break out your “interaction” segments (INTERACTION_TYPES) by the elements you want tested so that you can test specific data on those pages. The reasoning for this is that you can now leverage specific rules and other data validation/standardization features in ObservePoint to check that each interaction is performing as intended.
Here is an example of a rule “if” condition that is highly recommended to be used as a template. In this example, the configuration had a “linkType” of “allLinks”
This configuration of the rule will only apply to those elements that were intended to interact with from the selectors we configured for “allLinks” (e.g. only apply this rule to clicking on exit links; download links; add to cart interactions; video play events)
The second condition leveraging the data layer element is in case the page resulted in no interactions. This may because of many reasons, but ultimately means that when the page was returned to, the script wasn’t able to find that element again
The condition above means that we do not apply rules where we did not end up clicking on anything.
Once the "if" logic is done, you can configure your “than” logic. Here's the rule:
Prop 33 should be set and Evar 34 should be a value found in the data layer
Each page that performed an interaction will have done its best to “highlight” the element that got interacted with and will look like the following on the page:
Note: Some elements are extremely hard to highlight for an array of reasons such as: hidden behind another element, not being visible until another action is performed, is within something like a carousel where it seems like it should be visible, but is only visible at a specific moment, etc.
If you need to see those elements highlighted and it is a need to interact with elements prior, you can leverage the “action” attribute in the configuration of the INTERACTION_TYPES to perform those actions prior to interacting with your desired elements.
If nothing is visibly highlighted, there is a data layer value that is passed to help you determine which thing was clicked on.
If you’re on a page where this has happened, go to tags and search “data layer” and you will see a data layer with an account called interactionObject.
This object will contain several variable/values that can be used to determine the element.
The easiest way to use this is to copy the value in the “Element Selector” variable. Click on the value in its cell. This is the unique CSS selector for the element that was interacted with on.
Click on the button next to the link at the top to open the URL in a new tab, open the dev tools and go to the console. Type: document.querySelector(“<<paste that selector here>>”).
Hit enter and that should result in the element that was interacted with. You can right click it and scroll it into view, and reveal it in the elements panel. This should be a great way to determine exactly what was interacted with on.
Conclusion
The method above is the solution to interact and analyze all the elements on a page through Audits using the ObservePoint app. Following this guide will provide you all the information you need to implement this solution. Should you need further assistance, please contact an ObservePoint representative.