Forem: Edward Glush

I Built a Pre-Block Pixel Interceptor to Fix Our 38% Meta Signal Loss. Here's the Code.

Edward Glush — Sat, 21 Feb 2026 19:22:41 +0000

We were losing 38% of our purchase signals to Meta. Not misattributing them — losing them entirely. Meta's pixel never saw them. Neither did our ad algorithms. We were optimizing Advantage+ campaigns against 62% of our actual customers.

This is how we fixed it without paying $150/mo for Google Cloud sGTM.

Why Pixels Die Before They Reach Meta

Standard ad pixels fire an outbound HTTP request from the visitor's browser:

user converts → fbq('track', 'Purchase') → https://connect.facebook.net/...

Ad blockers intercept that request at the network level. uBlock Origin, Brave, Firefox Enhanced Tracking Protection — all block connect.facebook.net by default. iOS Safari adds another layer: ITP (Intelligent Tracking Prevention) nukes client-side cookies after 7 days, breaking the identity chain entirely.

The result: any user who bought 8 days after their first ad click is invisible to your pixel, even if they convert. We measured this against our Shopify ground truth and found:

GA4: 16% signal loss (202 reported vs 241 actual orders)
Meta: 38% signal loss (149 reported vs 241 actual orders)

The Fix: Intercept Before the Network Layer

The key insight: ad pixels attach to window.fbq, window.gtag, window.ttq, etc. These are just JavaScript functions. You can wrap them before the outbound request fires.

const wrapped = new Set();
const queue = [];

function wrapPixel(name) {
  const original = window[name];
  if (!original || wrapped.has(name)) return;

  window[name] = function (...args) {
    // ✅ Captured here — before any network request
    // No ad blocker can intercept a JS function call
    queue.push({
      platform: name,
      args: JSON.parse(JSON.stringify(args)), // deep copy
      timestamp: Date.now(),
      url: window.location.href,
    });
    flushQueue();

    // Let the original call proceed (may get blocked — doesn't matter now)
    return original.apply(this, args);
  };

  wrapped.add(name);
}

// Pixels often initialize asynchronously — poll until they exist
const TARGETS = ['fbq', 'gtag', 'ttq', 'pintrk', 'snaptr', 'rdt', 'twq'];
const huntingLoop = setInterval(() => {
  TARGETS.forEach(name => {
    if (window[name]) wrapPixel(name);
  });
}, 500);
setTimeout(() => clearInterval(huntingLoop), 10_000);

The queue gets flushed to your own first-party endpoint — something like https://events.yourdomain.com/collect. Ad blockers can't block your own domain without breaking your site entirely.

async function flushQueue() {
  if (queue.length === 0) return;
  const batch = queue.splice(0, queue.length);

  await fetch('https://events.yourdomain.com/collect', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ events: batch }),
    keepalive: true, // survives page unload
  });
}

Solving the ITP Cookie Problem

Wrapping gets you the event payload. But you still need to link it to the user's prior sessions — the TikTok click they made 10 days ago before Safari wiped everything.

The difference comes down to how you set the cookie:

// ❌ Client-side — ITP deletes this after 7 days (or sooner on cross-site loads)
document.cookie = `zy_uid=${userId}; max-age=31536000`;

// ✅ Server-side — Set-Cookie header survives ITP indefinitely (first-party)
// In your edge function / server route:
res.setHeader('Set-Cookie', [
  `zy_uid=${userId}; Max-Age=31536000; HttpOnly; Secure; SameSite=Lax; Path=/`
]);

When a user lands from any ad click, your edge function:

Reads click ID params from the URL (fbclid, gclid, ttclid, sclid, etc.)
Sets a durable first-party server-side cookie mapping zy_uid → click attribution data
On conversion 30 days later, that cookie is still there — readable server-side

This extends your attribution window from Safari's 7-day maximum to however long you want.

Server-Side Forwarding to Meta CAPI

Once events arrive at your endpoint, forward them to Meta's Conversions API. Unlike the browser pixel, CAPI calls come from your server — zero ad blocker risk.

// Node.js / Vercel Edge example
import crypto from 'crypto';

async function forwardToMetaCAPI(event) {
  const { platform, args, userId, ip, userAgent } = event;

  // Only forward Meta pixel events
  if (platform !== 'fbq') return;

  const [action, eventName, data] = args;
  if (action !== 'track') return;

  const payload = {
    data: [{
      event_name: eventName, // 'Purchase', 'AddToCart', etc.
      event_time: Math.floor(Date.now() / 1000),
      action_source: 'website',
      event_source_url: event.url,
      user_data: {
        client_ip_address: ip,
        client_user_agent: userAgent,
        // Hash PII fields — required by Meta
        em: data.email ? sha256(data.email.toLowerCase().trim()) : undefined,
        ph: data.phone ? sha256(normalizePhone(data.phone)) : undefined,
        fbc: event.cookies?.fbc, // Facebook click ID cookie
        fbp: event.cookies?.fbp, // Facebook browser ID cookie
      },
      custom_data: {
        currency: data.currency || 'USD',
        value: data.value,
        content_ids: data.content_ids,
        content_type: data.content_type,
      },
      event_id: `${userId}-${eventName}-${Date.now()}`, // for deduplication
    }],
    test_event_code: process.env.META_TEST_CODE, // remove in prod
  };

  await fetch(
    `https://graph.facebook.com/v18.0/${process.env.META_PIXEL_ID}/events?access_token=${process.env.META_CAPI_TOKEN}`,
    { method: 'POST', body: JSON.stringify(payload), headers: { 'Content-Type': 'application/json' } }
  );
}

const sha256 = (str) => crypto.createHash('sha256').update(str).digest('hex');

Important: use the same event_id for both the browser pixel event and the CAPI event. Meta uses this for deduplication — without it, you'll double-count conversions.

The Behavioral Signal Layer (Bonus)

Once you have a reliable first-party event pipeline, you can capture pre-conversion signals that standard pixels completely ignore.

These micro-behaviors predict purchase intent with meaningful accuracy:

// High-intent signals
const HIGH_INTENT = {
  pricingDwell: () => {
    // Track time spent on pricing/shipping pages
    if (!document.querySelector('.pricing, .shipping-info')) return;
    const start = Date.now();
    document.addEventListener('visibilitychange', () => {
      if (document.hidden) {
        const dwell = Date.now() - start;
        if (dwell > 30_000) sendSignal('pricing_dwell', { ms: dwell });
      }
    });
  },

  imageZoom: () => {
    document.querySelectorAll('.product-image').forEach(img => {
      img.addEventListener('wheel', throttle(() => sendSignal('image_zoom'), 2000));
    });
  },

  reviewDwell: () => {
    const reviews = document.querySelector('.reviews-section');
    if (!reviews) return;
    const observer = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting) {
        const start = Date.now();
        setTimeout(() => {
          if (document.querySelector('.reviews-section:hover') ||
              entry.isIntersecting) {
            sendSignal('review_dwell', { ms: Date.now() - start });
          }
        }, 20_000);
      }
    });
    observer.observe(reviews);
  },
};

// Friction signals
const FRICTION = {
  rageClick: () => {
    let clicks = [];
    document.addEventListener('click', (e) => {
      const now = Date.now();
      clicks = clicks.filter(t => now - t < 2000);
      clicks.push(now);
      if (clicks.length >= 3) {
        sendSignal('rage_click', { element: e.target.className });
        clicks = [];
      }
    });
  },

  paymentError: () => {
    // Watch for error messages near payment forms
    const observer = new MutationObserver(() => {
      const errors = document.querySelectorAll('.payment-error, .error-message, [class*="error"]');
      if (errors.length > 0) sendSignal('payment_error');
    });
    observer.observe(document.body, { childList: true, subtree: true });
  },
};

Push these signals to Meta CAPI as custom events. Meta's algorithm will start finding more users who behave like high-intent visitors, not just users who already bought.

What We Packaged Into Zyro

We turned all of the above into a single script tag at www.zyro.world — auto-intercepts 20+ pixels, handles ITP-resistant identity persistence, tracks 90+ attribution sources, captures 26 behavioral signals, and dispatches to Meta, Google, TikTok, Klaviyo, and 11+ other platforms simultaneously.

But everything in this post is implementable from scratch. The DIY path costs roughly:

Component	Eng Days
Pixel wrapping + queue	1–2 days
First-party edge endpoint	1 day
ITP-resistant cookie	0.5 days
Meta CAPI forwarding	1 day
Google Measurement Protocol	1 day
Behavioral signal capture	2–3 days

Total: ~7–8 days of engineering. Worth it if you're spending meaningful money on ads.

Gotchas I Wish Someone Had Told Me

Deduplication is critical. If your browser pixel fires AND your CAPI fires for the same event with different event IDs, Meta counts two conversions. Use a stable event_id (user ID + event name + session timestamp works).

keepalive: true on fetch. Without this, your events queue gets dropped when users navigate away mid-flight. keepalive: true tells the browser to complete the request even after the page unloads.

Consent first. If you're in the EU, you must check consent before capturing anything. Don't queue events before a positive consent signal. We check window.__tcfapi consent before initializing the hunting loop.

Deep copy the args. Some pixel libraries mutate their arguments after calling the function. JSON.parse(JSON.stringify(args)) ensures you capture the state at call time, not at flush time.

What approaches are others using for server-side attribution? Particularly curious if anyone's built their own fractional attribution model rather than relying on platform-reported numbers.

A/B Testing Is a Leaky Abstraction (And It’s Holding Modern Websites Back)

Edward Glush — Tue, 10 Feb 2026 07:43:29 +0000

As developers, we’re trained to spot leaky abstractions.

When a model simplifies reality too much, edge cases pile up, behaviour diverges, and the system starts lying to you.

After years of building analytics pipelines, experimentation engines, and real-time behavioural systems — most recently while building an adaptive growth platform called Zyro — I’ve come to a slightly uncomfortable conclusion:

Traditional A/B testing is a leaky abstraction for modern user behaviour.

It worked.
It was necessary.
But it no longer maps cleanly to how traffic behaves today.

The Original Assumption Behind A/B Testing

Classic A/B testing assumes:

A stable audience
Homogeneous intent
Static behaviour
A single global optimum

You create variants, split traffic evenly, wait for statistical significance, then deploy a “winner”.

That model made sense when:

traffic sources were limited
users arrived with similar context
sessions were isolated

None of that is true anymore.

Modern Traffic Is Heterogeneous by Default

Today, two visitors landing on the same URL can be fundamentally different:

One comes from Google with a research mindset
One comes from TikTok with zero patience
One arrives from ChatGPT already primed with context
One is a returning user carrying session history

Yet most experiments treat them identically.

From a systems perspective, that’s already a red flag.

You’re averaging over fundamentally different distributions.

Why “Global Winners” Are Usually Local Losers

Here’s the part most dashboards won’t show you.

When you declare a global winner, you often do so by flattening variance:

Variant A performs slightly better overall
But performs worse for specific cohorts
Those losses get hidden inside aggregates

So you ship something that’s “better on average” while quietly degrading performance for high-intent traffic segments.

This isn’t a statistics problem.

It’s a modelling problem.

Behaviour Happens Before Conversions

Most analytics systems anchor on terminal events:

purchase
signup
submit

But behaviour doesn’t start there.

The meaningful signals appear earlier:

hesitation
comparison
repeated scrolling
policy checking
copying product details
bouncing between tabs

These are not noise.

They are state transitions.

And state transitions are what systems should respond to.

This insight didn’t come from dashboards.
It came from building systems that had to react to behaviour as it was happening, not after the fact.

The Shift From Experiments to Control Systems

While building Zyro, we stopped thinking in terms of “experiments” and started thinking in terms of control systems.

A control system:

observes signals continuously
reacts in real time
adapts based on feedback
never “finishes” optimisation

In this model:

A/B testing becomes one input
Not the governing mechanism

Multi-armed bandits, intent scoring, and source-aware routing aren’t replacements for testing.

They’re what naturally emerges when optimisation is treated as a live system instead of a batch process.

Why This Is a Developer Problem (Not a Marketing One)

Most growth tooling is designed for dashboards, not systems.

Developers care about:

feedback loops
latency
reliability
failure modes
state awareness

Once you view optimisation through that lens, it becomes obvious why manual experimentation struggles:

it’s slow
it’s coarse-grained
it reacts after the fact
it assumes stationarity where none exists

Modern systems don’t wait for significance.

They adapt.

The Direction This Is Heading

The next generation of websites won’t run “tests” in the traditional sense.

They’ll behave more like adaptive systems:

source-aware rendering
intent-weighted decisions
continuous learning
server-enriched signals
automated feedback into acquisition channels

This isn’t theory.

It’s the architecture you end up with when you try to make optimisation actually match how users behave.

Final Thought

A/B testing didn’t fail.

It succeeded so well that we stopped questioning its assumptions.

But as traffic becomes more fragmented and behaviour more stateful, optimisation needs to evolve from experiments into systems.

When an abstraction starts leaking, the fix isn’t more tooling.

It’s a better model.

And that’s the kind of problem developers are very good at solving.

Tracking the "Invisible Web": How I built an engine to detect traffic from ChatGPT, Claude, and Perplexity

Edward Glush — Wed, 21 Jan 2026 22:23:53 +0000

The Problem: The "Black Box" of Modern Analytics

I spent years frustrated with the same two problems in marketing tech:

The "Direct" Lie: Google Analytics (GA4) dumps huge chunks of traffic into "Direct" because it can't parse the referrer. In reality, this is often "Dark Social" (Slack, Discord) or the new wave of AI Answer Engines.

Fragile A/B Tests: Client-side testing tools rely on CSS selectors that break the moment a developer changes a class name.

I decided to build Zyro to fix this. It’s an optimization platform that combines a server-side A/B tester with a finance-grade attribution ledger.

Here is a breakdown of the architecture and the specific technical challenges I solved.

Catching the "Invisible" Traffic (AI & LLMs)

Standard analytics tools look for standard referrers. But traffic from LLMs often gets stripped. I built a Universal Source Detector that parses over 50+ specific traffic signatures.

Instead of a simple regex, we built a "Traffic Brain" that specifically identifies:

AI Engines: ChatGPT, Perplexity, Claude, Gemini, Copilot.

Ad Identifiers: Parsing gbraid, wbraid (Google), fbclid (Meta), and ttclid (TikTok).

Email Platforms: Detecting _kx (Klaviyo) and mc_cid (Mailchimp).

The Tech: We store these massive, parameter-heavy URLs in a custom SQL schema using NVARCHAR(MAX) columns to ensure zero data truncation, something standard schemas often fail at.

The "Visual Intelligent" Editor (No More Broken Selectors)

Most A/B tools force you to "blind click" on elements, generating fragile CSS paths. I took a different approach using HtmlAgilityPack.

Backend Crawler: Instead of relying on the browser, our backend crawls the live URL and parses the DOM tree server-side.

X-Ray Vision: On the frontend, we render elements in a sandboxed iframe on hover. This allows us to "see" the code structure before editing.

Asset Pipeline: When a user swaps an image, we don't hotlink. We automatically upload it to AWS S3 and serve it via CloudFront. This means the "test" variation often loads faster than the original site.

"God Mode" Attribution (Linear Multi-Touch)

The biggest challenge was attribution. "Last Click" is lazy. I built a Linear Multi-Touch Model with a 30-day lookback window.

The Logic: When a transaction happens (via Stripe webhook or Bank Wire), the engine:

Fetches the user's entire 30-day history.

Filters "Direct" Noise: If other marketing sources exist (e.g., a Facebook ad click 2 weeks ago), "Direct" is explicitly ignored.

Splits the Revenue: It mathematically divides the dollar value across all valid touchpoints and writes it to a dbo.AttributionLedger.

Syncing "Intent" to Ad Pixels

We don't just track pageviews. We track Intent Scores (0–100) based on micro-behaviors:

High Intent: Copying text, dwelling on pricing, reading reviews.

Friction: Rage clicks, dead clicks, form abandonment.

The Cool Part: The system dispatches these events server-side to ad platforms (Meta CAPI, Google Ads). This allows you to retarget users who showed "High Intent" but didn't buy, drastically lowering CAC.
The Stack

Backend: .NET / SQL Server

Crawling: HtmlAgilityPack

Algo: Thompson Sampling (Multi-Armed Bandit) for auto-optimizing traffic.

Infra: AWS S3 + CloudFront.

What’s Next?

I’m currently refining the "Anti-Flicker" engine (customizable timeouts to prevent FOOC) and expanding the AI detection library.

I’d love to hear how you guys are handling attribution for ChatGPT traffic. Are you seeing it show up as "Direct" in GA4 too?

🚀 Try Zyro "God Mode" & Fix Your Attribution

Why I built Zyro: stopping guesswork in revenue, attribution, and A/B testing

Edward Glush — Tue, 20 Jan 2026 19:19:54 +0000

After running my own online business for years, I kept running into the same frustrating problem:
analytics told me where traffic came from, A/B tests told me what variation won — but neither told me who was actually trying to buy or where I should focus next.

Clicks looked great. Revenue didn’t always follow.

Most tools optimise for engagement or last-click attribution. Ad platforms optimise for signals that don’t always reflect real buying intent. And experimentation tools treat every visitor the same, regardless of where they came from or how close they are to purchasing.

So I built Zyro to solve this problem.

Check out Zyro — revenue-first attribution & A/B testing for e-commerce

Zyro is a revenue-first attribution and A/B testing platform for e-commerce. It detects high-intent behaviour on a website in real time (things like pricing engagement, offer interaction, and key conversion signals) and sends those signals back to ad platforms to help optimise toward buyers instead of low-quality traffic. This helps reduce CAC without increasing spend.

On the experimentation side, Zyro lets you A/B test offers, messaging, and experiences based on intent or traffic source — for example showing different variations to users coming from ChatGPT, Facebook, Reddit, Google, or email campaigns. Instead of running one-size-fits-all tests, you can tailor experiments to how and why users arrive.

Zyro also provides revenue attribution across 50+ traffic sources, giving a clearer picture of what actually contributes to sales so marketing budgets can be allocated with confidence.

I built Zyro from scratch as a solo founder, based on the pain points I experienced first-hand. I’m sharing it now to get feedback from other founders, marketers, and engineers who’ve dealt with attribution, experimentation, or conversion challenges.

Happy to answer questions or hear what others have struggled with in this space.