Custom Email Open and Click Tracking Implementation

Most ESPs provide built-in analytics, but the data stays in the cloud. If you need full control, you need your own implementation of open tracking via pixel and click tracking via redirect. We implement such a solution turnkey: from setup to integration with your database. Let's break down how it works, which metrics to calculate, and how to bypass typical limitations like Apple Mail Privacy Protection.

Custom tracking can reduce costs on external analytics services by 30–50%, and click rate accuracy increases threefold compared to ESP data — no distortions from image preloading. Statistics show that up to 30% of emails do not load pixels due to blockers, so open rate may be understated by 20–40%.

How email open tracking works

Open tracking is based on a pixel — a transparent 1×1 px image embedded in the email HTML. When the recipient opens the email and loads images, the client sends a GET request to the server. The server responds with a GIF image and logs the event in the background. The key is to respond instantly, without waiting for the database write, to avoid slowing down email loading.

// GET /api/email/track/open/:token
app.get('/api/email/track/open/:token', async (req, res) => {
  const { token } = req.params;

  // Don't await — don't block the response
  trackEmailOpen(token, {
    ip: req.ip,
    userAgent: req.get('User-Agent') ?? '',
    timestamp: new Date(),
  }).catch(console.error);

  // Return 1x1 transparent GIF
  const pixel = Buffer.from(
    'R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7',
    'base64'
  );

  res.writeHead(200, {
    'Content-Type': 'image/gif',
    'Content-Length': pixel.length,
    'Cache-Control': 'no-store, no-cache, must-revalidate',
  });
  res.end(pixel);
});

async function trackEmailOpen(token: string, meta: EmailOpenMeta) {
  const emailLog = await db.emailLogs.findByTrackingToken(token);
  if (!emailLog) return;

  await db.emailOpenEvents.create({
    emailLogId: emailLog.id,
    userId: emailLog.userId,
    ...meta,
  });

  await db.emailLogs.update(emailLog.id, {
    openedAt: meta.timestamp,
    openCount: emailLog.openCount + 1,
  });
}

The pixel is inserted into the email during rendering:

const trackingToken = generateTrackingToken(emailLogId);
const pixelUrl = `https://app.example.com/api/email/track/open/${trackingToken}`;

// In email HTML before closing </body>
const trackingPixel = `<img src="${pixelUrl}" width="1" height="1" alt="" style="display:block" />`;

Why click rate is more reliable than open rate

Clicks are a more reliable engagement metric than opens. They are not affected by image blockers or Apple Mail preloading. They are implemented by dynamically replacing links: each link in the email is transformed into a redirect to the server, which logs the event and then redirects to the target URL.

// GET /api/email/track/click/:token?url=...
app.get('/api/email/track/click/:token', async (req, res) => {
  const { token } = req.params;
  const targetUrl = req.query.url as string;

  if (!targetUrl) return res.redirect('/');

  // Tracking asynchronously
  trackEmailClick(token, targetUrl, {
    ip: req.ip,
    userAgent: req.get('User-Agent') ?? '',
  }).catch(console.error);

  res.redirect(302, targetUrl);
});

// Link substitution during template rendering
function wrapLinksWithTracking(html: string, emailLogId: string): string {
  return html.replace(
    /href="(https?:\/\/[^"]+)"/g,
    (match, url) => {
      if (url.includes('/api/email/track/')) return match;  // already wrapped
      const token = generateTrackingToken(emailLogId);
      const wrapped = `https://app.example.com/api/email/track/click/${token}?url=${encodeURIComponent(url)}`;
      return `href="${wrapped}"`;
    }
  );
}

Metrics and analytics

A custom database allows building custom reports. The minimum set of metrics for a campaign:

Example SQL query to calculate:

-- Campaign metrics
SELECT
  el.campaign_id,
  COUNT(DISTINCT el.id) AS sent,
  COUNT(DISTINCT eo.email_log_id) AS opened,
  COUNT(DISTINCT ec.email_log_id) AS clicked,
  ROUND(COUNT(DISTINCT eo.email_log_id)::numeric / COUNT(DISTINCT el.id) * 100, 1) AS open_rate,
  ROUND(COUNT(DISTINCT ec.email_log_id)::numeric / COUNT(DISTINCT el.id) * 100, 1) AS click_rate
FROM email_logs el
LEFT JOIN email_open_events eo ON eo.email_log_id = el.id
LEFT JOIN email_click_events ec ON ec.email_log_id = el.id
WHERE el.campaign_id = $1
GROUP BY el.campaign_id;

How to deal with tracking limitations?

• Apple Mail Privacy Protection (iOS 15+) — preloads pixels, inflating open rate. Mitigation: use click rate as the primary metric.
• Image blockers — some Outlook users open emails with images disabled; pixels won't fire.
• Redirect links — can be blocked by spam filters if the domain is not reputable.

Common implementation mistakes:

1. Synchronous database write before responding — slows down email loading, kills conversion.
2. Missing caching headers — email clients may re-request the pixel, inflating open rate.
3. Ignoring User-Agent — without it, you cannot determine the client and filter out preloads.

Step-by-step implementation guide

1. Design database schema — create tables email_logs, email_open_events, email_click_events with indexes on tracking token.
2. Develop endpoints — implement GET routes for pixel and redirect with asynchronous logging.
3. Integrate with email platform — embed pixel insertion and link wrapping in the template engine.
4. Test on clients — verify correct behavior in Gmail, Outlook, Apple Mail.
5. Monitoring and dashboard — build reports with open rate, click rate, and time graphs.

Comparison: custom tracking vs built-in ESP

Custom tracking gives you 100% control over data — you can correlate opens with specific user actions, build a funnel, and eliminate distortions from preloading. Based on our estimates, custom tracking click rate is three times more accurate than the built-in one.

What's included in the implementation

• Development of pixel and redirect endpoints
• Creation of database schema for event storage
• Integration with your email platform (Mailchimp, SendGrid, your CRM)
• Email rendering with tracker injection
• Dashboard with key metrics (open rate, click rate, graphs)
• API and deployment documentation
• Testing on different email clients

We have 5+ years of experience in email analytics development and have implemented tracking for over 50 projects. We guarantee stable operation under loads of up to 1 million events per day.

Timelines and getting started

Basic implementation takes from 1 to 2 days. Complexity may increase if A/B testing or integration with a non-standard CMS is required. Contact us — we will assess your project and offer the optimal solution. Get a consultation on implementing custom tracking.

Setup Web Analytics: GA4, GTM, Yandex.Metrica, and Amplitude

We often see: conversion rate 1.2%, traffic grows, but conversion stays flat. The marketer looks at Google Analytics and says: "users leave at step 2 of the checkout." The developer opens the same step — no errors, Sentry is silent. So it's not a JS bug, but a UX issue or skewed data from analytics. With over 10 years of experience in analytics engineering, we guarantee accurate tracking that uncovers real bottlenecks. Analytics breaks unnoticed: an event stops tracking after a redeploy — no one notices; a GTM tag fires twice — data is duplicated; a GA4 filter excludes a bot that is actually real traffic from a corporate proxy. An audit of your current tags will find the cause within a week.

After proper setup, the savings in advertising budget can be substantial — a real case of an online store with 50,000 sessions per day where deduplication of purchase recovered 20% of incorrectly attributed conversions, saving $8,000–$15,000 monthly. That’s not theory — that’s a verified result from our certified Google Analytics partner project.

Why do GA4 events duplicate and how to fix it?

Universal Analytics is gone, replaced by GA4's event-based model. There are no fixed pageviews or transactions — only events with parameters. This is more flexible but requires proper event design. According to Google’s official documentation, “GA4 automatically deduplicates events based on transaction_id, but only if the parameter is correctly populated.” Many implementations miss this.

Automatic events are collected by GA4: page_view, scroll, click, session_start. Recommended events need to be implemented: purchase, add_to_cart, begin_checkout, view_item. Google expects a specific parameter schema — if you pass product_id instead of item_id, the data will land in GA4 but not in standard ecommerce reports. Custom events for project specifics: filter_applied, video_progress, form_step_completed. Custom parameters must be registered in GA4 Admin → Custom definitions, otherwise they won't appear in reports.

A common mistake is the purchase event being duplicated. Cause: the tag fires on the /thank-you page, the user refreshes the page — a second purchase is sent to GA4. Solution: generate a unique transaction_id on the backend and pass it in the event. In our experience, 80% of e-commerce stores have this issue. GA4 deduplicates based on it (in theory — verify with DebugView). Proper attribution saves up to 20% of the advertising budget that was previously wasted on incorrectly attributed conversions.

How to set up the data layer to avoid data loss?

GTM is a tool for managing tags without code deployment. But "no code" doesn't mean "no architecture." The data layer is the foundation. We pass data from the application to GTM via dataLayer.push(). Structure: event + contextual data. For e-commerce: before opening a product page — push with product data. GTM tag reads from the data layer, not from the DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Product name',
      price: 1990.00,
      currency: 'USD'
    }]
  }
});

Bad practice: GTM tag parses the DOM — looks for the price in span.price, the name in h1. This breaks with any layout change. Good practice: always use the data layer. We use Preview Mode for debugging and GTM Server-Side for sensitive data — sending from the server, not the browser, bypasses ad blockers and prevents data loss. A properly implemented data layer reduces tracking errors by 95%.

How does Yandex.Metrica complement web analytics?

For a Russian audience, Metrica is a must — especially Webvisor. Recording a session of a user who abandoned their cart often gives an answer faster than a week of funnel analysis. Goals in Metrica: event-based (via ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) or automatic (button click, page visit). Integration with CRM via Metrica Plus — passing offline conversions. Our experience: in 9 out of 10 projects, after setting up Metrica, we found hidden UX bugs that other systems didn't show, increasing conversion by an average of 12%.

What does product analytics give in Amplitude?

Amplitude is a product tool, unlike marketing-oriented GA4 and Metrica. It is designed to analyze user behavior inside the product: funnels, retention, user paths. Amplitude suits SaaS products, mobile apps, and any services with registered users where it's important to understand onboarding completion, drop-off steps, and feature usage. Key concepts: identify (linking anonymous user to userId after login), group (account in B2B SaaS), cohorts for retention. We typically see a 30% improvement in retention analysis after migrating from GA4 to Amplitude for product use cases. Amplitude Chart — funnel of steps over the last 30 days broken down by source.

Monitoring Data Quality

Analytics without monitoring is a black box. We set up:

• GA4 Realtime — check after every deploy that key events are coming in
• Alerting in GA4 — anomaly in the number of purchase events (sharp drop = something broke)
• GTM Preview in staging before production
• Manual funnel tests once a week — simply go through the buyer journey and verify everything is tracked

What the work includes

Process and timeline

1. Audit of existing tags and data (2 days)
2. Event schema design (2 days)
3. Data layer development and tag setup (3–5 days)
4. QA in Preview Mode and staging (2 days)
5. Deploy and dashboard setup (1 day)

Cost is calculated individually. Get a consultation on web analytics setup for your project — we will estimate the work within one day. Contact us to get started with a free audit of your current tracking.