Global Tracking Snippet
What is Global Tracking Snippet
This is the master template that shall be customized for each pageview event type.
How to Implement Global Tracking Snippet
Follow the steps below:
- Copy and paste the Global Page View Tracking Snippet & install it on all pages.
- Map the global variables and customize the snippet to add the tracking parameters for specific pixel types (page view events or other events).
Please note that Global Tracking Snippet is not a pixel type on its own. It is a base snippet that is always changed and customized to track an actual pixel type.
Global Variables Checklist for Page View Pixels
The following section lists the global tracking variables for page view pixels. Send these variables for all page view pixels as per the indicated requirements.
JavaScript Implementation
Required variables
Variable | Value type, example | Description* |
---|---|---|
acct_id | string, "1235" | The Bloomreach-provided Account identifier. Value must be consistent with the account_id value passed in the API call. |
ptype | string, "homepage" | Maps your site's page type classifications to the values Bloomreach expects for page type classifications. It is required on all page views, including desktop, mobile, and tablet versions. Bloomreach has 8 page types: homepage , product , category , search , conversion , content , thematic and other . |
title | String, "Blue Lace Dress" | This is the title of the current page. Bloomreach uses titles when listing pages in analytics reports for Insights. If you do not have tags set in your HTML, you must add this variable to your pixel. Every page on your site should have a different title. |
Conditional tracking variables for specific use cases
Variable | Value type, example | Description |
---|---|---|
domain_key | string (case-sensitive),"bloomreach_fr" | Set Domain Key to the name of the product Catalog that would be searched against on the page where the event occurred. It corresponds to the Search API's domain_key parameter and should match. If you do not query the Search API with a domain_key parameter, the value’s default is the name of the Account's primary Catalog. The Bloomreach-provided ID of the domain receiving the request. This parameter identifies the specific site language version when one account ID hosts multiple site versions with different languages. Bloomreach uses this value to ensure that only query and analytics data that pertain to that language are used for respective features. This parameter is only required if your Account has more than one product Catalog. Otherwise, domain_key should not be declared in the pixel, as this will cause issues with analytics. During the technical kickoff call, the Bloomreach integrations team will inform you whether domain_key will be required for your pixel integration. |
test_data | bool, "true" | When set to true, this flags pixel data to be ignored during analytics processing. This ensures that you can fire the pixel in a test environment, allowing you to perform pixel validation without affecting your analytics data. We recommend not declaring test_data=true in the pixel for your live site. While it is possible to send test_data=false on the live site, it is not an ideal implementation. |
tms | string, "tlm" | The name of the Tag Management system that should be filtered out. In case of migration from one tag management system to another, there may be a transition time frame when the pixel is fired by two systems simultaneously. Setting the tms param will allow the Bloomreach analytics system to filter out duplicate pixels. Use tms="tlm" for Tealium. This parameter is optional and only required during the transition time from one tag management system to another. Leave this field empty if this scenario does not apply. |
user_id | string, "947345478564" | If you track users via a universal customer ID, populate this parameter with that ID. This should be an anonymized string. It should not contain the user's email or other personally identifiable information. This parameter is only required if you wish to identify your users via a universal customer ID. This will allow Bloomreach to recognize users in a way that is aligned with your system for various personalization features. The correct implementation of this parameter can vary for different user scenarios. A common mistake is to set user_id to "null" or "undefined". Learn what parameter value you can set for each scenario in the user_id recommended implementation article. |
view_id | string (case-sensitive), "10200" | The name of the product catalog view that would be searched against on the page where the event occurred. It corresponds to the Search APIs view_id parameter and should match. If you do not query the Search API with a view parameter, the value should be left empty. Identifies the catalog view to show when one Bloomreach account ID hosts multiple site versions with unique product catalog characteristics, such as product price, availability, or title. Bloomreach uses View ID value to display the right product information for a user based on their site view. This parameter is only required if you integrate on a site with multiple site versions with unique product catalog characteristics. Otherwise, view_id should not be declared in the pixel, as this will cause issues with analytics. In the early stages of scoping and designing an integration project, Bloomreach will work with your teams to determine whether view_id will be required for your pixel integration. Value must be consistent with the view_id value passed in the feed and API call. |
Non-JavaScript Implementation
Required variables for Non-JS Implementation
To implement the Global tracking snippet in the native app, you must include the following variables in addition to the variables mentioned above.
Variable | Value type, example | Description |
---|---|---|
cookie2 | String, - uid=3510849277068:v=11.8:ts=1636626614546:hc=1` - URL Encoded cookie2=uid%3D3510849277068%3Av%3D11.8%3Ats%3D1636626614546%3Ahc%3D1 | Anonymous identifier for a particular browser or device instance using a randomly generated unique user ID. Value is usually stored as a browser cookie. Format is:uid={{cookie_uid}}:v={{tracker_version}}:ts={{unix_timestamp}}:hc={{hitcount}} cookie_uid - random 10-13 digit number generated on first visit in the browser or device and stored as a cookie or in local storage on the device, must respect customer privacy choices, example JS: Math.round(Math.random() * 10E12);tracker_version - version of used tracker (from SDK); for direct API calls use “app”ts - unix epoch timestamp in seconds when cookie_uid was generatedhitcount - value should be 1 for a new visitor, and incrementing with every subsequent pixel fired. |
rand | String, 0.4566879906 | A random number that acts as a cache buster to make sure browsers and proxies don't cache requests. |
ref | String,“http://v11.0-android.app.homeoasis.com/category/mens-clothes” | For a mobile native app, both "ref" and "url" parameters follow a similar synthetic structure that is used for identifying the content within the app rather than actual navigable URLs. |
title | string, "Blue%20Lace%20Dress" | Screen name of the app view. |
type | string, "pageview" | The type of tracking fire. For page view pixels, type=pageview. |
url | String,“http://v11.0-android.app.homeoasis.com/category/mens-clothes” | The "url" parameter should be a synthetic unique URL composed of a static base URL and the screen app screen name. To maintain uniqueness, the base URL should be prefixed with OS and application version, should be prefixed with the page type classification, and then followed by the title. For example, synthetic URL: http://{releaseversion}-{operatingSystem}.app.merchantname.com/category/mens-clothes. The URL could be structured with the ptype and title matching the values of their respective variables in the pixel. This URL is used to uniquely identify the page/content being viewed for tracking purposes. The release version and operating system have proven to be useful for troubleshooting the release that caused it. |
For a full list of required and optional variables, see Pixel Reference
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.
Global Tracking Snippet for Page View Pixels
The following are tracking snippets for both JavaScript and Native app implementations.
JavaScript Implementation
<script type="text/javascript">
var br_data = br_data || {};
br_data.acct_id = "<Bloomreach Provided Account ID>";
br_data.ptype = "<Bloomreach Page Type>";
br_data.title = "<title of current page>";
br_data.domain_key = "<Bloomreach Domain Key>";
br_data.view_id = "<Bloomreach View ID>";
br_data.user_id = "<Bloomreach User ID>";
br_data.debug = true; // remove for production
br_data.test_data = true; // remove for production
// INSERT the page type specific tracking parameters in the Global Tracking Script
(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:
- Android SDK
- iOS SDK
- Direct API request
https://p.brsrvr.com/pix.gif?
acct_id=6702
&cookie2=uid%3D1e7724c751a3f6e6241018d150144832e7528383%3Av%3Dapp%3Ats%3D0%3Ahc%3D1
&rand=79069731271669680
&type=pageview
&title=Blue%20Lace%20Dress
&url=http%3A%2F%2Fmerchantname.app%2Fproduct%2Fblue%2520lace%2520dress
&ref=http%3A%2F%2Fmerchantname.app%2Fcategory%2Fdresses
&ptype=[]
// INSERT the page type specific tracking parameters here
Discovery SDKs for application native pixel integration
For details on using the Discovery Android and iOS SDKs for specific Native App Implementation, refer to their respective linked guides.
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 pixel works as expected.
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.
Updated 6 months ago