Overview
OnLoad beacon for every single product, leading to different implementation and performance considerations.Key Differences
Feature Comparison
Feature | Legacy beacons | Standard/Universal beacons |
|---|---|---|
Data transmission | Sends an | Includes product data at the placement level |
Performance impact | Higher network requests and load | More efficient, fewer requests |
Implementation complexity | Requires per-product tagging | Consolidated tracking logic |
Use case | Legacy setups requiring detailed per-product tracking | Modern implementations optimizing efficiency |
Feedback mechanism | No feedback on missing products | Supports status codes for suppressed/not rendered products |
Optimization potential | Limited visibility into why products didn’t appear | Enables fill rate optimization and revenue improvement |
OnLoad event for every product on the page.This means:- Each product gets a separate beacon request.
- Increased network load due to multiple requests.
- No feedback mechanism to indicate why certain products didn’t make it onto the page, limiting optimization potential.
Key Features of Universal Beacons
-
Minimized response:
- Product-level
OnLoadBeaconsare removed, leaving just a singleOnLoadBeaconat the placement level. This simplifies the overall tracking process.
- Product-level
-
Reduced requests:
- By having a single
OnLoadBeaconper placement, the total number of beacon requests is minimized, leading to less network traffic and improved performance.
- By having a single
-
Feedback mechanism:
- Universal beacons include a feedback mechanism to report on why certain products were not rendered.
- This allows for detailed reporting and better optimization of the overall fill rate - leading to more revenue.
Examples
Legacy Response Example
Here is a sample response leveraging Legacy beacons with individualOnLoad events at the product level:
Universal Beacon
Call example
Here’s an API call example usingcurl.
Notice the forceuniversal=1 parameter:
Response example
Notes on the Response
OnLoadBeaconsat the product level are empty:- Notice that the
OnLoadBeaconfor each product is empty. This is expected as there is only oneOnLoadBeaconat the placement level when leveraging universal beacons.
- Notice that the
- Single
OnLoadBeaconper placement- The
OnLoadBeaconat the placement level contains all the necessary information, significantly reducing the number of beacons sent.
- The
- Action parameter
- The
OnLoadBeaconat the placement level includes the parameteraction=universal, indicating that the response is using universal beacons.
- The
Handling non-rendered Products
For SKUs that were not rendered, you must append additional parameters to the universalOnLoadBeaconto avoid inaccurate impression and attribution counts. Here’s how to handle unrendered products:
-
Specify unrendered SKUs: Use the
exparameter to list the SKUs that were not rendered. -
Add exclusion reasons: Use the
stparameter to specify the reasons for each unrendered SKU.
Example
Status codes
Migrating from Legacy to Universal beacons
-
Enable the
forceuniversalparameter in pre-production
Add the parameter&forceuniversal=1to all API calls in your pre-production environment. -
QA
Collaborate with your TAM to test the new beacon logic in the pre-production environment to ensure it functions correctly. -
Deploy to production
Once the QA phase is successful, release the new logic into the production environment with the&forceuniversal=1parameter included in all API calls. -
Internal update
Criteo will update your internal configuration to automatically send universal beacons in your ad responses, eliminating the need for the&forceuniversal=1parameter. -
Parameter removal
You can then remove the&forceuniversal=1parameter from your API calls at your convenience.