Overlay: Technical Overview
The Parse.ly Overlay allows editors to quickly understand the performance of links on homepages and landing pages. It also provides historical comparisons for particular page positions (“slots”), so that it’s easy to see whether a given link is doing better or worse than previous links in the same position.
How Parse.ly tracks slot performance
When slot tracking is enabled, Parse.ly monitors the exact location on a homepage or index page that a user clicks to get to a post page (see Distinguishing between “posts” and “pages” to understand how Parse.ly categorizes webpages). When a click occurs, the Parse.ly tracker determines the link’s XPath and stores it in the browser. Then, when the target page loads, the Parsely tracker on that page reads the stored XPath and includes it in the slot data sent with its first
The Overlay bookmarklet then creates badges in your browser by doing the reverse: retrieving traffic data from our servers and matching each element on the page with the XPath that was stored on click, along with traffic data for that post URL.
With slot tracking enabled, link URLs are treated as referrers for their target pages. For example, clicking a link on a page
http://examplesite.com/home with the target
href="http://examplesite.com/feature1" tells the Parsely tracker that the
pageview event sent from
/feature1 should have
/home as its referring URL.
Slots tracking works best for customers with high traffic to their homepage or index pages. High traffic means multiple clicks through multiple slots within any given 10-minute window.
Please note that Slots data is not designed to work for the following cases:
- When a slot receives fewer than 1 click within the last 10 minutes.
- Slots linking to Non-posts (click here to see how Parse.ly distinguishes between Posts and Non-posts).
- Slots linking to external sites, i.e., sites that do not share the same SiteID.
Defining slots with
To ensure that historical slot comparisons are accurate, it’s important to define slots so that link XPaths remain stable and consistent over time, regardless of the content they contain or the presence of other transient page elements (such as ad units, consent modals, etc.).
To illustrate how to add the necessary markup to an existing page, let’s consider this simplified example:
<section id="hero"> <div> <article> <a href="/feature/1"><img src="/photo1"></a> <div> <a href="/feature/1"><h2>Main Story Headline</h2></a> <p>A small description</p> </div> <ul> <li><a href="/feature/2"><h3>Related Story 1</h3></a></li> <li><a href="/feature/3"><h3>Related Story 2</h3></a></li> </ul> </article> </div> </section> <section id="list-1"> <ul> <li><a href="/news/1"><h2>News Headline 1</h2></a></li> <li><a href="/news/2"><h2>News Headline 2</h2></a></li> <li><a href="/feature/1"><h2>Main Story Headline</h2></a></li> </ul> </section>
To define a slot, add a
data-parsely-slot attribute with a unique value to a semantically appropriate DOM element. The XPath will be calculated by traversing upwards through the parent elements of the clicked link until an element with a defined
data-parsely-slot value is found (or the top of the document is reached).
While it’s not necessary to define a slot for each link on the page, it is important that the internal structure of each slot is consistent. For example, if a widget always has a list of ten stories with links, it’s fine to define a single slot at the list level. But if the list occasionally contains an additional list element with an ad, then it’s better to define each slot at the list-element level.
For the example above, it might be sufficient to add the attribute to just a couple elements:
<section id="hero"> <div> <article data-parsely-slot="feature-story-1"> <a href="/feature/1"><img src="/photo1"></a> <div> <a href="/feature/1"><h2>Main Story Headline</h2></a> <p>A small description</p> </div> <ul> <li><a href="/feature/2"><h3>Related Story 1</h3></a></li> <li><a href="/feature/3"><h3>Related Story 2</h3></a></li> </ul> </article> </div> </section> <section id="list-1"> <ul data-parsely-slot="latest-news-list"> <li><a href="/news/1"><h2>News Headline 1</h2></a></li> <li><a href="/news/2"><h2>News Headline 2</h2></a></li> <li><a href="/feature/1"><h2>Main Story Headline</h2></a></li> </ul> </section>
data-parsely-slot values on a page should be unique, just as if you were defining
id attributes. It’s also useful to use semantically meaningful values, as we have above.
There are often multiple link elements that point to the same target page (for example, a thumbnail and headline that both link to an article). As long as the
href attribute of these links is exactly the same, and the links share the same
data-parsely-slot ancestor, the Parse.ly Overlay will combine their data into a single, aggregated slot.
In the example above, there are two links in the
feature-story-1 slot that point to
/feature/1. While they have different XPaths (
//*[@data-parsely-slot="feature-story-1"]/div/a, respectively), because they share the same
data-parsely-slot ancestor, they will be grouped together. But the link nested in
latest-news-list will not be grouped, even though it points to the same page.
When there are no page elements with
data-parsely-slot attributes, the tracker will instead calculate XPaths by traversing up the DOM tree from the clicked link until it finds the first element with an
id attribute (or it reaches the top). In the initial example above, the Xpath for the first link would be
//*[@id="hero"]/div/article/a. In a real webpage, with many deeply nested elements, these XPaths can become long and brittle, depending on where
id attributes are used.
In this default mode, if two links have the exact same
href attribute and have bounding rectangles in close physical proximity, their data will be aggregated into a single slot.
Last updated: April 21, 2023