How Pixel Alert System works?
The Pixel Alert system watches every hotel's tracking pixel (the "Last Pixel" field in Q-BI / Dynamics) and flags accounts where the pixel has stopped firing. A stale pixel usually means a broken or paused integration — the hotel keeps taking bookings, but Quinta stops reliably tracking or attributing them. The goal is to catch this before it costs revenue reporting accuracy or triggers a client complaint.
Once a day at 3:00 PM (Tunis time). It only sends a message if there's something to report — no alert means no stale accounts that day.
Which accounts are checked- Only accounts with status Won or Premium are checked (free/pending/churned/hub accounts are excluded).
- Accounts on SiteMinder or TheBookingButton are excluded entirely — the pixel can't technically be installed on those booking engines, so staleness there isn't meaningful.
- Central / master group accounts are excluded. Some records in the system aren't real properties — they're administrative placeholders for a hotel group (for example, a record literally named "MedPlaya" sitting under group "MedPlaya", or "MS Hoteles" under group "MS"). These never take real bookings, so a pixel that never fires on them isn't a problem — they're filtered out before anything is evaluated.
"Days since last pixel" is the age of the most recent tracked booking-engine hit. A recent Test Pixel run (Velma's manual pixel test, within the last 15 days) is treated as evidence the integration itself is fine, so it softens Alert/Critical down to Monitoring — it doesn't clear the item, but it lowers the urgency. If a pixel has never fired at all, that's shown as the word "never" instead of a day count, and it's always treated as Critical.
|
Days since last pixel |
Status shown |
With a Test Pixel in the last 15 days |
Included in alerts? |
|---|---|---|---|
|
0 – 5 days |
OK |
n/a |
No |
|
6 – 11 days |
Monitoring |
n/a |
Channel card / analysis only — not sent to CS |
|
12 – 24 days |
Alert |
Downgraded to Monitoring |
Yes |
|
25+ days, or never |
Critical |
Downgraded to Monitoring |
Yes — highest priority |
Monitoring accounts are not sent to you directly. They're informational — visible on the channel card and the daily analysis summary — but you're only pinged once an account actually crosses into Alert or Critical. That way a DM from this system always means "worth a look," not "just so you know."
Group hotels vs. standalone hotelsFor hotel groups, the system looks at the group as a whole before flagging any single property:
- If at least one hotel in the group fired a pixel within the last 3 days, the entire group is considered healthy and none of its properties are flagged that day — even if some individual properties look stale. This avoids false alarms when one property's booking engine is simply quieter than another's on a given day.
- If no property in the group has fired a pixel in 3 days, the group is flagged using its single most-recently-active property as the reference record (shown with a "REF" tag).
Some accounts have been stale for so long — over 60 days, or they've never had a pixel recorded at all — that they'd never naturally surface through day-to-day monitoring. Rather than dumping the entire historical backlog on CS at once, the system introduces a small batch of these (currently up to 5 per day) into the normal alert flow, tagged BACKLOG so you can tell "this integration has been broken for a long time" apart from "this went stale this week." Once introduced, a backlog account keeps appearing like any other stale account until its pixel starts firing again — at which point it drops out on its own.
What you receive as a CS ownerOnce a day, if you own at least one stale account, you get a direct Teams message (from the Flow bot) listing only your affected accounts:
- Account name (and group name, if applicable)
- Status: Alert or Critical, and days since last pixel (or "never")
- Date of the last Test Pixel run, if any
- A "BACKLOG" tag if the account is a long-dormant one just being introduced
Copies of every CS message also go to the Account Management team for oversight — you don't need to loop them in separately.
What CS owners don't need to act on- The Teams channel card — a top-10 snapshot across all accounts, for visibility only.
- The daily "Pixel Analysis" summary sent to Account Management — aggregate counts and a company-wide breakdown by CS owner, used for tracking trends, not a per-account action item.
If 2 or more accounts on the same booking engine are stale, and at least 75% of that booking engine's accounts haven't fired a pixel in 3 days, it's flagged as a high-risk booking engine in the summary. This usually points to a booking-engine-side or integration-wide issue rather than isolated account problems — worth mentioning if you spot your account's booking engine on that list.
Recommended action when you get an alert- Critical or Alert: check the account's booking engine setup in Velma / Q-Data and confirm the pixel is still installed on the live site; run a Test Pixel to verify.
- BACKLOG-tagged accounts: same as above, but treat it as a known long-standing gap rather than a fresh emergency — worth flagging if it needs a bigger fix than a quick check.
- If the booking engine risk flag mentions your account's booking engine, treat it as a possible platform-wide issue and flag it up rather than troubleshooting the account in isolation.
For anything about the rules, thresholds, or a message you weren't expecting, reach out to Akram(AHK)