user@gitdiot:~/blog/how-i-operate/email-tracking$
● online ~/index ~/about
$ cat ./content/operating/email-tracking.md --render
~/blog/how-i-operate/email-tracking
how-i-operate email-tracking deliverability gmail Mar 24, 2026 · 8 min read

How We Built Email Open Tracking That Doesn't Hurt Deliverability

Using Google Workspace, a branded signature, and the Admin Reports API to close the analytics loop on outbound sales emails.

The Problem With Traditional Email Tracking

Most sales tools track email opens the same way: inject a hidden 1x1 transparent pixel into the email body, usually with display:none or positioned off-screen. When the recipient's email client loads that invisible image, the server logs the request as an "open."

This worked well in 2015. In 2026, it's a liability.

Modern spam filters — especially Gmail's — have learned to recognize these patterns. A hidden image with no visual purpose, served from a domain that isn't the sender's primary domain, with a unique URL per message? That's a tracking pixel. Filters can:

For outbound sales, where deliverability is everything, this creates a paradox: the tool you're using to measure engagement is actively reducing it.

The Fix: Make the Tracker Something the Email Needs

The insight is simple: email signatures already contain images. Every professional email has a company logo. What if the logo is the tracker?

Instead of appending a hidden pixel, we serve the company logo from a tracking endpoint. The URL contains a unique identifier per email, but the image itself is a real, visible, branded asset that belongs in the email.

<a href="https://unitedlogic.ai/">
  <img src="https://agentcrm.unitedlogic.ai/t/a1b2c3d4-e5f6-7890-abcd-ef1234567890.png"
       width="180" alt="United Logic" />
</a>

From the recipient's perspective, this is a normal email signature with a company logo. From the server's perspective, every image load is a trackable event.

What the spam filter sees

Before (hidden pixel):

<img src="https://track.example.com/t/abc123.gif" width="1" height="1"
     style="display:none" alt="" />

After (logo signature):

<table style="font-family:Arial,sans-serif;font-size:13px;">
  <tr><td>
    <a href="https://unitedlogic.ai/">
      <img src="https://agentcrm.unitedlogic.ai/t/abc123.png"
           width="180" alt="United Logic" style="display:block;border:0;" />
    </a>
  </td></tr>
  <tr><td><strong>Ryan Slipakoff</strong><br>President & Co-Founder</td></tr>
  <tr><td>[email protected]<br>unitedlogic.ai | LinkedIn</td></tr>
</table>

The Server Side: 12 Lines That Do Everything

The tracking endpoint is trivially simple. When a request comes in:

  1. Serve the real logo image immediately (don't block on database writes)
  2. Log the open event asynchronously
app.get('/t/:trackingId.png', async (req, res) => {
  const { trackingId } = req.params;

  // Serve the logo immediately
  res.set({
    'Content-Type': 'image/png',
    'Content-Length': String(LOGO_PNG.length),
    'Cache-Control': 'no-store, no-cache, must-revalidate',
  });
  res.end(LOGO_PNG);

  // Log the open asynchronously
  // ... insert into email_events, update open_count
});

The no-cache headers are critical — without them, the email client will cache the image after the first load, and subsequent opens won't generate requests.

The logo file is loaded once at startup from disk. There's no external dependency, no CDN, no image processing. Every request gets the same bytes.

Closing the Loop: Google Admin Reports API

Open tracking tells you if someone opened your email. But what about the other side — did the email actually arrive?

If you're sending from Google Workspace, the Admin Reports API gives you delivery-level telemetry that most sales tools can't access:

The Email Analytics Stack

Combining these two data sources gives you a complete picture:

Sent --> Delivered? --> Opened? --> Replied?
  |         |           |         |
  |         |           |         +-- Gmail polling (thread detection)
  |         |           +------------ Logo tracking endpoint
  |         +------------------------ Google Admin Reports API
  +---------------------------------- Gmail draft creation + send

Each stage answers a different question:

Stage Source Question
Sent Gmail API (draft -> send) Did we send it?
Delivered Admin Reports API Did their server accept it?
Opened Logo tracking endpoint Did they read it?
Replied Gmail thread polling Did they respond?
Bounced Gmail polling + Admin API Is this address dead?

Bounce Detection: Two Signals Are Better Than One

Gmail sends bounce notifications as reply messages in the original thread. Our Gmail polling cron detects these by checking for messages from mailer-daemon@ or subjects containing "Delivery Status Notification."

The Admin Reports API catches bounces that Gmail doesn't surface as messages — like silent drops from recipient servers that accept the message at the SMTP level but never deliver it to the inbox.

Cross-referencing both sources gives you a more complete bounce list, which keeps your sender reputation clean.

What Open Tracking Can and Can't Tell You

It can tell you:

It cannot tell you:

The inbox proxy problem

Gmail proxies images through its own servers (googleusercontent.com). This means:

Apple Mail Privacy Protection (since iOS 15) pre-loads all images regardless of whether the user opens the email. If your recipient uses Apple Mail, every delivered email looks "opened."

Our approach: We track opens but don't over-index on them. Opens inform prioritization — a contact who opened 5 times in 2 days gets a follow-up call. But we weight replies and engagement signals from the Admin API more heavily than raw open counts.

The Deliverability Checklist

The logo-as-tracker trick removes one negative signal. But deliverability is a system, not a single fix. Here's the full stack:

Authentication (table stakes)

Sending behavior

Content signals

List hygiene

Monitoring

Implementation Notes

Signature generation

The signature is generated per-email with the sender's details:

const SENDERS = {
  CRM1: { name: 'Ryan Slipakoff', title: 'President & Co-Founder', ... },
  work: { name: 'Michael Paige', title: 'CEO & Co-Founder', ... },
};

Each email gets a unique tracking_id (UUID v4) assigned at creation. The logo URL includes this ID, so every email has a distinct tracking URL even though the served image is identical.

Gmail draft workflow

  1. AI generates the email body using career context and persona data
  2. Body is converted from plain text to HTML
  3. Branded signature with tracking logo is appended
  4. MIME message is base64url-encoded
  5. Draft is created in Gmail via the API with CRM labels
  6. Salesperson reviews, edits, and sends manually

The human-in-the-loop step (review and send) is intentional. The AI writes the first draft; the salesperson owns the final message. This keeps the emails authentic and avoids the robotic tone that triggers spam filters and recipient distrust.

Database schema

-- Each outgoing email gets a tracking_id
ALTER TABLE outreach_log ADD COLUMN tracking_id UUID DEFAULT gen_random_uuid();
ALTER TABLE outreach_log ADD COLUMN opened_at TIMESTAMPTZ;
ALTER TABLE outreach_log ADD COLUMN open_count INTEGER DEFAULT 0;

-- Granular event log
CREATE TABLE email_events (
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    outreach_id  UUID REFERENCES outreach_log(id),
    tracking_id  UUID NOT NULL,
    event_type   TEXT NOT NULL,  -- 'open', 'delivery', 'bounce'
    ip_address   INET,
    user_agent   TEXT,
    created_at   TIMESTAMPTZ DEFAULT NOW()
);

Results

Since switching from hidden pixels to the logo signature:

The tracking mechanism is invisible to the recipient but visible to the spam filter in the right way — it looks like a legitimate business email because it is one.

Built with AgentCRM — an AI-powered CRM agent running on Google Workspace, Supabase, and Claude.

subscribe.sh

Get the field notes

Weekly dispatches from an aging tech worker's refactoring. No spam, no thought leadership.

no spam · only high-signal logic