By the Digital Empire Regulatory Research Team (PixelProof Analysis Team) · Reviewed by Andy Gaber, Founder, Digital Empire Holdings LLC · Published September 1, 2026 · Last updated September 1, 2026
The Shopify DTC founders we work with already live in Klaviyo — abandoned-cart flows, welcome sequences, post-purchase upsells, VIP segments. Adding another dashboard to check every morning is a losing pattern; the alerts eventually stop getting checked, the pixel eventually breaks, and no one notices until Advantage+ Shopping cost-per-purchase drifts 40 percent above baseline six days later. The alternative is to route the pixel-health alerts into the same lifecycle-marketing surface the operator already opens every day. That is what the Charlie16 (2026-08) Klaviyo connector does — it fires a pixelproof.scan.complete metric into a connected Klaviyo account each time a scan runs, and the operator's existing Klaviyo flow builder handles the alerts from there. This guide is the step-by-step flow build.
Before building the flow, you need three things in place: (1) a PixelProof account with active scans configured against your storefront; (2) a Klaviyo account (free tier works for testing, paid tier required for production email volumes); and (3) the Klaviyo connector configured in PixelProof's /andy/integrations/klaviyo operator surface with a valid scoped Klaviyo private API key.
The scoped Klaviyo API key needs three permissions: events:write (to fire the metric), profiles:write (to write the store owner profile if it does not exist yet), and metrics:read (to look up the metric ID for deduplication). Create the key in Klaviyo Account then Settings then API Keys then Create Private API Key, select the three specific scopes, and paste the key into the PixelProof integration UI. The key is stored encrypted at rest on PixelProof's side (AES-256-GCM); the PixelProof operator surface shows the last-4 characters for confirmation but does not display the full key after the initial paste.
Once the key is in place, run a manual scan from the PixelProof dashboard to trigger the first pixelproof.scan.complete metric event into Klaviyo. In Klaviyo, navigate to Analytics then Metrics; the new metric appears in the list within a few minutes of the scan completing. That confirmation is the signal that the connector is working and the metric is ready to drive flows.
Each pixelproof.scan.complete metric event arrives in Klaviyo with a structured payload:
• scan_id — unique identifier for the scan, cross-referenceable back to the PixelProof scan record.
• storefront_url — the fully-qualified URL of the storefront scanned (e.g., https://example.myshopify.com).
• scan_status — one of healthy, warning, or broken.
• failed_check — the specific check that failed if scan_status is not healthy; empty otherwise. Values include pixel_missing, capi_share_below_baseline, event_id_mismatch, cmp_blocking_both_channels, aem_domain_drift.
• scan_timestamp — ISO-8601 timestamp of the scan.
• fix_snippet_url — a URL to the paste-ready fix snippet for the specific failure; empty on healthy scans.
• previous_status — the status of the previous scan on the same storefront, for detecting status flips (healthy-to-broken is the primary alert trigger).
These fields are addressable inside the Klaviyo flow builder via the {{ event.<field_name> }} template-tag syntax. Email templates and flow conditions can reference any of them without additional configuration.
The first-alert flow is the primary alerting surface. Its job is to notify the store owner (and anyone else on the alert list) within minutes of a scan detecting that the pixel-health status just flipped from healthy to warning or broken.
Step 1: create the flow. In Klaviyo, navigate to Flows then Create Flow then Create From Scratch. Name it “PixelProof first-alert on status flip.”
Step 2: configure the trigger. Set the trigger to a metric trigger on pixelproof.scan.complete. Add a trigger filter: scan_status equals warning OR broken. Add a second trigger filter: previous_status equals healthy. Together, these filters mean the flow only fires when the current scan detects a break that was not present on the previous scan (a fresh break, not an already-known-broken state).
Step 3: add the deduplication filter. Add a flow filter on the trigger step: profile has not received an email from this flow in the last 24 hours. This prevents the flow from double-firing if a break flaps back and forth between healthy and broken within the same day.
Step 4: add the email step. Add an email step. Subject line: [PixelProof] {{ event.scan_status|upper }}: {{ event.failed_check }} on {{ event.storefront_url }}. Body: include the failed check, the fix-snippet URL, and a direct link to the PixelProof scan detail page. Keep the email short — the point is fast triage, not comprehensive analysis. A three-paragraph email with a clear next action outperforms a longer email that the owner has to scroll through on a phone.
Step 5: publish the flow. Set the flow to Live status. Klaviyo starts triggering the flow on incoming scan events from that point forward.
The persistence-alert flow catches the case where a break has been reported (via Flow 1) but has not been fixed within 48 hours. Its job is to escalate — add the profile to a “needs a call” segment, or send a second alert to a broader distribution list, or fire a Slack webhook to the operations channel.
Step 1: create the flow. Name it “PixelProof persistence-alert 48h.”
Step 2: configure the trigger. Same metric trigger on pixelproof.scan.complete. Trigger filter: scan_status equals broken.
Step 3: add a delay step. Add a Time Delay step of 48 hours. This puts the flow's email/action step 48 hours after the initial broken-state trigger.
Step 4: add a conditional split. Add a Conditional Split step that checks whether the storefront has had a healthy scan within the last 48 hours (using a Klaviyo conditional-split query against the pixelproof.scan.complete metric with scan_status equals healthy). If yes, exit the flow (the break was fixed). If no, proceed to the escalation action.
Step 5: add the escalation action. Options include a second email to a broader distribution list (add the operations manager and CTO), a webhook step to a Slack channel (using Klaviyo's native webhook action), and/or a profile-property update that adds the profile to a “pixel-broken-persistent” segment for downstream flow triggering.
Step 6: add the deduplication filter. Flow filter: profile has not received this flow's persistence-alert email in the last 72 hours. This prevents the escalation from double-firing on a break that persists more than 48 hours.
Step 7: publish. Set to Live.
Some operators like a positive confirmation when a break is fixed. The resolution-confirmation flow fires when the scan status flips from warning or broken back to healthy, and sends a brief acknowledgment email to the owner.
Configure it like Flow 1 but with inverted trigger filters: scan_status equals healthy, previous_status equals warning OR broken. Add a 24-hour deduplication filter. The email confirms the fix, references the scan that reported the resolution, and includes a link to the scan detail page for the owner to verify. Many teams skip this flow — the absence of a persistence-alert is confirmation enough — but for teams that want an explicit “you fixed it” signal, the flow is a five-minute build.
Beyond the alerting flows, the pixelproof.scan.complete metric can drive segments in Klaviyo the same way any custom metric can. Two segments are worth building:
• Currently-broken segment. “Last pixelproof.scan.complete event has scan_status equal to broken or warning.” This segment is the live count of storefronts under a current pixel issue — useful for account-owner dashboards and for post-hoc analysis of break frequency.
• Healthy-for-30-days segment. “All pixelproof.scan.complete events in the last 30 days have scan_status equal to healthy.” This segment identifies storefronts that have been continuously healthy for a month — useful for upsell / lifecycle nudges (“your pixel has been healthy for 30 days, here is what else PixelProof monitors”).
Segments update in near-real-time as scan events arrive, and any flow triggered on segment entry / exit can pick up the segment change. That is the surface for building lifecycle sequences that respond to pixel-health as an operating input, not just as an alert.
Klaviyo does not have a native “send test metric event” feature, so the safest way to test the flows before enabling them in production is to manually trigger a scan on a test storefront from the PixelProof dashboard, verify the metric arrives in Klaviyo, and then step through the flow builder's preview mode to confirm the trigger fires, the deduplication filter passes, and the email renders with the correct dynamic fields.
For flows with time delays (the persistence-alert 48-hour delay), temporarily shorten the delay to 5 minutes during test, run through a full trigger-and-recover cycle to confirm the conditional split correctly detects the healthy scan, then reset the delay to 48 hours before setting the flow to Live. This test pattern catches the most common flow-build mistake: a conditional split that incorrectly evaluates the healthy-scan query and routes the escalation email even after the break has been fixed.
For an agency or a multi-store operator running PixelProof scans on multiple storefronts, the Klaviyo connector supports either (a) one Klaviyo account per store (each with its own scoped API key) or (b) one shared Klaviyo account across all stores, with the storefront URL as the profile identifier. Pattern (a) works best when each store has its own owner team and its own alerting distribution; pattern (b) works best for agency-model operators who want a single Klaviyo view across all managed stores.
Under pattern (b), the profile identifier passed with each metric event is the storefront_url, and the flows are keyed by that identifier via the standard Klaviyo profile-property matching. Alerting distribution is configured per-store by attaching the appropriate team members as followers on the store-specific profile, and the flow's email step sends to the followers rather than to a fixed distribution list. This pattern requires more upfront profile setup but scales cleanly to dozens or hundreds of managed stores under one Klaviyo account.
PixelProof's continuous background scan is the input; the Klaviyo flow is the output. The flow does not do the monitoring — PixelProof does that, scanning the storefront and the Meta Pixel + Conversions API event stream continuously and detecting breaks the moment they happen. The Klaviyo flow does the routing — taking the scan result and delivering it into the operator's existing lifecycle-marketing surface without requiring another dashboard, another Slack channel, or another email inbox to check.
For the underlying storefront-integration pattern that makes the scan itself possible (how Klaviyo and the Meta Pixel actually fit together on Shopify), see the Klaviyo + Meta Pixel integration guide. For the deeper API-authentication details on the scoped Klaviyo private key, see the public integration docs. For the Conversion Lift use case where continuous monitoring is the difference between a valid readout and an invalidated study, see the Conversion Lift guide.
The pixelproof.scan.complete metric arrives in Klaviyo as a metric event with a structured event payload. The payload includes the scan ID, the storefront URL scanned, the scan status (healthy, warning, or broken), the specific check that failed (if any), the timestamp of the scan, and a paste-ready fix snippet URL for the failure. The metric is a standard Klaviyo metric event and can drive flows, segments, and profile updates the same way any native Klaviyo metric (Placed Order, Started Checkout) can.
The two most common flow patterns are (1) a first-alert flow triggered on any scan-status flip from healthy to warning or broken, sending an email to the store owner within minutes of the scan completing; and (2) a persistence-alert flow triggered when the status has been in warning or broken for more than 48 hours, escalating to a "needs a call" segment or a Slack-channel handoff. Some operators also build a resolution-confirmation flow triggered when the status flips back to healthy after a break, sending a "you fixed it" acknowledgment.
No. Klaviyo's native flow builder handles the trigger, delay, condition-branch, and email-send steps without any custom code. The only external dependency is having PixelProof connected to your Klaviyo account with a scoped write-only API key (documented at /docs/integrations/klaviyo); once that connection is in place, the pixelproof.scan.complete metric shows up in the Klaviyo metric picker like any other custom metric.
The Klaviyo private API key needs three scoped permissions: events:write (to fire the pixelproof.scan.complete metric), profiles:write (to write the store owner profile if it does not exist yet), and metrics:read (to look up the metric ID for deduplication). The key never touches other Klaviyo endpoints, cannot read other customers' data, and is stored encrypted at rest (AES-256-GCM). Klaviyo's scoped-key framework is documented at developers.klaviyo.com/en/docs/authenticate_.
The recommended pattern is to gate the first-alert flow with a "profile has not received this email in the last 24 hours" filter, so the owner gets one alert per rolling day on the same break. The persistence-alert flow is gated separately with a "profile has been in the broken-status segment for more than 48 hours and has not received a persistence alert in the last 72 hours" filter, so the escalation fires once per rolling three days. Together, the two flows produce roughly one first-alert-per-day plus one persistence-alert-per-three-days pattern for a persistent break, rather than a torrent of every-scan alerts.
Then the Klaviyo flow is optional. PixelProof sends scan alerts via email, Slack, webhook, or Klaviyo depending on which channels are enabled on the account. The Klaviyo flow pattern is specifically for operators who already live in Klaviyo for lifecycle marketing and want the pixel-health alerts to arrive in the same tool they already open every morning. If your team lives in Slack, use the Slack channel instead; if your team lives in email, use email. The Klaviyo integration is additive, not required.
Yes. The scan metric can drive any Klaviyo flow the operator wants. Some accounts use the scan-healthy status over a rolling 30-day window to trigger a "you are all good, here is what else PixelProof does" educational sequence. Others use scan-broken persistence to trigger a "here is the paid-tier feature that would have alerted you sooner" upgrade nudge. The flow surface is the Klaviyo native flow builder; whatever the operator can express there, they can drive off the scan metric.
pixelproof.scan.complete metric.Once the connector is live, the flow build above takes 20-30 minutes end to end. From then on your pixel-health alerts arrive in the same tool you already open every morning — no new dashboard, no new inbox.