Content Page View Pixel

What is Content Page View Pixel


This pixel is used to track the activity of non-product pages that are dedicated to a specific piece of content.This may include blog posts, articles, product descriptions, instructional videos, etc., that are powered by Discovery Content search (otherwise, track the page as Other page view). Since you are able to use Bloomreach to power multiple catalogs on your site, we need to know which Catalog the current content belongs to.

👍

Bloomreach powers both types of content - Product related content and non-product content (with Content Search). This makes it extremely crucial for Bloomreach to understand which content is being interacted with. This will allow Bloomreach to aggregate the user behavior signals independently for each content type and optimize the user experience accordingly.

This grouping of similar types of content is called a Catalog.

The definition of what is contained in the Catalog is up to you as the customer. For example, you can choose to have Blogs, Articles, and Videos within a single catalog or split it across three catalogs. The implication is that on the Bloomreach side, a new search index is created for each catalog, and you will need to make an additional Content Search API call to access the information in a different index. Each new index would result in additional costs due to integration costs to Bloomreach.

You can discuss the best setup for your site with your Bloomreach representative. If no catalog is passed in the pixel, it is assumed to be a product catalog.

How to Implement Content Page View Pixels


  • Go to your Content Page Template and add the content-specific tracking parameters in the Global Tracking snippet.
  • When your content page (or portions of it) is loaded dynamically via AJAX, remember to add additional handlers for single page application tracking.

Content Page View Variables Checklist


The following lists the tracking variables required specifically for Content page view pixels. Please note that these must be included in addition to the Global Page View variables.

VariableValue type, exampleDescription
catalogsarray of Catalog objects,[{ name : "<example_en_prd>" }]List of catalogs that are shown in the page. In case the page has multiple tabs, only the catalogs of the selected (and visualized) tabs should be included.

If multiple catalogs are shown in the active page (or tab), all of them should be included.

If you are integrating Content Search, you must add br_data.catalogs to every page view pixel. You can include br_data.catalogs with the other global tracking parameters.
item_idstring, "recipe115718079035"Unique ID of the item being shown in the page. This identifier should match the item_id as specified in the content feed.
item_namestring, "California Avocado Omelette Recipe"Name or the title of the content page.

📘

For a full list of required and optional variables, see Pixel Reference

Catalogs format

You will have to manually format the catalogs parameter for native app implementation.

  1. Example catalogs parameter: &catalogs=cat0%3Dcontent_en%3Av0%3Dstore123.v1%3Dstore456%21cat1%3Dproduct%3Av0%3Dstore123.v1%3Dstore456
  2. The catalog name is encoded by prefixing "cat" + "the index of the catalog starting from 0" + "=" + "the catalog name"
  3. Each catalog in catalogs is separated by an "!"
  4. View IDs
  • The view_id is encoded by prefixing "v" + "the index of the view_id starting from 0" + "=" + "the view_id"
  • Catalog name and view_id are separated by a ":"
  • Multiple view_ids are separated by a "."

Implementation scenarios for catalogs

ScenarioExample
Single catalog, no viewscat0=content_en
Multiple catalogs, no viewscat0=content_en!cat1=product
Single catalog, one viewcat0=content_en:v0=store123
Single catalog, multiple viewscat0=content_en:v0=store123.v1=store456
Multiple catalogs, one has multiple views and one has no viewscat0=content_en:v0=store123.v1=store456!cat1=product
Multiple catalogs, both have multiple viewscat0=content_en:v0=store123.v1=store456!cat1=product:v0=store123.v1=store456

🚧

Examples here are not percent-encoded. Remember to percent encode your parameters for native app implementation.

Implementing Pixel in a Test Environment

If you are implementing the pixel in a test environment (development, staging, UAT, etc.), you must add the test_data variable. When set to “true”, this flags pixel data to be ignored during analytics processing. Read more about the test_data variable here.

📘

Your Content search pixel integration might vary based on your Bloomreach Discovery implementation. Read this guide to learn more about various integration scenarios.

Tracking Snippets for Content Page View Pixels


The following are the customized tracking snippets for both JavaScript and Non-JS environments. Here ptype is “content” for the Content Page View Pixel.

JavaScript Implementation

<script type = "text/javascript">

  var br_data = br_data || {};
  br_data.acct_id = "<Bloomreach Provided Account ID>";
  br_data.domain_key = "<default value>";
  br_data.ptype = "content";
  br_data.debug = true; // remove for production
  br_data.test_data = true; // remove for production


  br_data.catalogs = [ { name : "<example_en_prd>" } ];
  br_data.item_id = "recipe115718079035";
  br_data.item_name = "California Avocado omelette Recipe";

(function ()
{
    var BrTrk = document.createElement('script');
    BrTrk.type = 'text/javascript';
    BrTrk.async = true;
    BrTrk.src = "//cdn.brcdn.com/v1/br-trk-{{BloomReach Account ID}}.js";
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(BrTrk, s);
})();
</script>

👍

Copying Snippet from Events Managment

You can copy the personalized tracking snippet from the Events Management application. We recommend using personalized snippets instead of copying from the documentation page. Currently, only acct_id and debug values are populated in the snippet. In future feature iterations, we will add domain_key, view_id, and other variables to further personalize the snippet for easy click-copy use.

Non-JavaScript Implementation

To integrate Bloomreach Pixels in a Non-JS Environment, you can choose one of the following options:

https://p.brsrvr.com/pix.gif?acct_id=5001
&cookie2=uid%3D8167986775218%3Av%3D15.0%3Ats%3D1702884946487%3Ahc%3D7
&ref=https%3A%2F%2Fwww.content.com%2Fshop%2Fhow-to-shop-online
&rand=0.8098872495779994
&rand=20220615173951
&title=Avocado%20omelette
&user_id=10002879530
&ptype=content
&type=pageview
&url=https%3A%2F%2Fwww.content.com%2Fshop%2Fhow-to-shop-online
&catalogs=cat0%3Dcontent_en
&item_id=recipe115718079035
&item_name=California%20Avocado%20omelette%20Recipe

Validate Pixel Implementation


If you’re integrating the Pixel, you can start tracking the test Pixel data using Events Management. It gives you a broad overview of your Pixel’s health in an instant. You can continue using this when you go live.

🚧

Integration mode in Events Management

If you wish to inspect individual events from your test environment in real time, add debug=true. Such events will be treated as test data and will show in the Integration mode of the Events Management within seconds. Otherwise, you can inspect events in the Live mode with a delay of up to 2 hours.

For web validation

Once Pixel implementation is complete, use the Pixel Validator Chrome Plug-in to validate if the content page view pixel is working as expected. Follow the scenarios listed in the Test Scenarios - Page View guide.

Troubleshooting


If you’re seeing a large drop in Content Page Views in Pixel reports, debug using this article.

Monitor and Manage Pixel Data


For long-term monitoring, use Pixel Monitor to get more detailed trend lines and set pixel error alerts. We recommend that you subscribe to pixel alerts.