Pixels Event Status: Pixel QA + Monitoring
The Pixel Event Status page can be used to monitor that the expected actions are being passed to Rockerbox, at the expected volume and with the expected variables.
This is especially critical when implementing Rockerbox pixels or troubleshooting any unexpected behavior of the on-site data passed to Rockerbox.
Navigating the Pixel Event Status Page
QA'ing your Pixel Events
The Pixel Event Status page can be particularly helpful for QA'ing your pixel implementation, to ensure data is being passed to Rockerbox as expected. Please see below for general guidance on QA'ing your pixels.
- Check that all pixels you implemented during onboarding appear as actions on the pixel events page. Same-day data is available, but on a slight delay due to the nature of the aggregations.
- If you're unsure which actions are expected or required, check in with your Rockerbox implementation team
- At minimum, all accounts should see 'view' and identify' actions, regardless of your specific implementation (for example, conversion events passed to Rockerbox via batch file or webhook)
- Confirm that the volume of pixel fires against your conversion events are aligned with your expectations
- Select a date range to compare conversions against. Dates and hours are reported in UTC timezone.
- See aggregate counts and unique pixel fires in the table, or use the chart to examine hourly pixel fire volume
- For more comparison analysis against your source of truth, download the .csv of raw pixel fires. Due to size, this may take a few minutes to download.
- Confirm that the required variables are being passed on each action by examining the % of non-null variables. See below for general guidance on how often variables are expected for common actions. Note, the required variables per action may vary based on your specific implementation.
Action | Variable Requirements (based on standard implementation) |
view | N/A |
identify | Passed on >0% of pixels: - email and/or external_id |
purchase | Passed on 100% of pixels: - email and/or external_id - order_id - revenue - coupon - address_street_1 - address_state - address_city - address_zip_code |
Detecting Anomalous Pixel Activity
Rockerbox aims to proactively alert you of any pixel anomalies that might impact our ability to track or attribute on-site events. To that, a series of standard checks are run on an hourly basis to quickly catch any activity that deviates from Rockerbox's expectations of your data based on historical information from your site.
Anomaly Alerting
All anomalies detected by Rockerbox are visible in the Event Status page of the UI. If any active anomalies exist, you will also see an alert on the Integrations page under Orders & Conversions. No email-based alerting is currently supported.
Anomaly checks are run on an hourly basis, comparing the past hour's data with historical data. Anomalies exist for 7 days after the most recent last_seen timestamp, after which point they are removed to maintain accuracy and avoid confusion.
Anomaly Types
The below describes the type of anomalies that Rockerbox monitors for, and the logic used for each. Further customization of anomalies is not currently supported.
Anomaly Type | Logic | What is Monitored |
overall pixel volume decrease | A baseline is calculated to identify the median pixel volume observed for the same hour increment and same day of week over the past 4 weeks. An alert will be fired under the following circumstances:
| Actions Monitored:
|
non-null variable decrease | A baseline is calculated to identify the average rate at which parameter values are populated on a given action over the preceding 24 hours. An alert will be fired under the following circumstances:
| Variables Monitored (across all actions):
* variable names must be an exact match. For ex. address_zipcode is not monitored |
Anomaly Status
Given that anomalies are compared to a historical context of 'normal' activity, there may be instances when an anomaly is raised that your team has further information on.
To avoid any confusion by your team on what's an open issue vs expected behavior vs irrelevant, Rockerbox offers your team controls on how anomalies appear in the Rockerbox UI. This is done by setting the status of each anomaly.
Status | Definition | When to Use |
Active | Rockerbox will continue to alert against an active anomaly until the last seen timestamp is > 7 days ago. | You are actively investigating an anomaly and want open issues to be visible to yourself and your team. |
Snoozed | The anomaly will be moved to a status = snoozed. Anomalies of the same type for the same action will continue to be alerted on in the future. | Anomaly is expected or resolved. You wish to clear this specific record, but still wish to see anomalies of this type + action in the future. Ex. you saw a low volume sales day after an extended promotional period. The drop in volume was flagged as anomalous behavior. |
Deactivated | Any anomalies of this type for this action and variable will no longer be alerted against. | You no longer wish to see anomalies of this type for this action and variable (where applicable). Ex. you're phasing out a certain action or renaming a variable. |