Moving Beyond the Pixel Swamp

In university digital strategy, marketing teams and web developers share the exact same mission—connecting prospective students with life-changing academic programs.

Recruitment campaigns move fast. When an enrollment marketing team or agency partner launches an initiative for an undergraduate preview day or professional master’s degree, they need fast, reliable campaign attribution to know what is working and report return on ad spend. Historically, the quickest path was dropping a vendor tracking pixel directly onto an “Apply Now” button or inquiry form.

Over time, as multiple colleges, departments, and campaign partners run concurrent efforts, that tag-based approach creates unintended friction for everyone. Client-side tag containers swell with competing scripts and DOM-based triggers. Browser privacy protections and tracking blockers intercept third-party tags, leading to frustrating discrepancies between marketing campaign dashboards and actual verified applications in the student information system. Meanwhile, every extra third-party script running on the page chips away at Core Web Vitals and page speed.

Nobody enjoys those reconciliation headaches. To support our marketing colleagues while protecting site performance and student privacy, we shifted our approach. We stopped treating web analytics as an ad-hoc collection of browser tags, and started building telemetry as a collaborative, internal API and data contract.

Balancing Governance with Campus Autonomy

Decentralization is the natural state of higher education. A major university operates like a city, spanning dozens of colleges, health clinics, research centers, and administrative units publishing across a patchwork of architectures—from modern static site generators and headless content hubs to enterprise CMS platforms and custom web applications.

Marketing and recruitment teams need the agility to measure campaigns without waiting on custom code deployments for every new tracking request. At the same time, platform teams need to safeguard site speed, accessibility, and student data privacy.

Treating telemetry as an internal API resolves that tension by creating a shared standard. Instead of injecting unvetted third-party JavaScript into students’ browsers for every campaign, the university publishes an authoritative Event Menu. Platform engineers and marketing strategists agree upfront on the vocabulary of key campus interactions—calls to action, program search queries, recruiter directory clicks, and application starts. Once captured cleanly at the source, those events become a trusted data stream that any downstream marketing or analytics platform can consume.

The Telemetry Pipeline

Building telemetry as an API means creating a clean, multi-layered architecture where each tier has a distinct role.

[Layer 1 - The Declarative DOM]
         │ (Plain HTML data attributes with zero tracking scripts)
         ▼
[Layer 2 - Delegated Client Dispatcher]
         │ (Assembles event_id, event_time, and interaction payload)
         ▼
[Layer 3 - The Server Gateway]
         │ (Validates, deduplicates, and sanitizes outgoing data)
         ▼
[Layer 4 - Downstream Consumers]
   ├── GA4 & BigQuery (Longitudinal modeling and institutional research)
   └── Meta CAPI / Snap Conversions API (Campaign attribution for marketing partners)

Layer 1 — The Declarative DOM

Content authors and front-end developers never have to write custom tracking scripts or juggle vendor naming conventions. Across our component libraries—whether in a modern static site framework, a headless content hub, or an enterprise CMS theme—components simply output semantic data-* attributes on interactive elements.

A defining characteristic of this layer is that it is intentionally centered on user interface elements. It models the components that visitors physically see and interact with—buttons, hero cards, navigation menus, accordions, and preview cards. By binding the contract directly to UI elements in the markup, analytics becomes a natural extension of component design. If a button exists in the design system, its tracking contract is already declared.

In fact, you can see this in the markup of this very site. The “View all” call to action on the home page declares its contract directly in HTML:

<a href="/notes" class="btn btn-ghost btn-sm"
   data-event="cta_click"
   data-component="home_field_notes"
   data-label="view_all_notes"
   data-section="field_notes">
   View all &rarr;
</a>

Layer 2 — The Client Dispatcher and Data Contract

A single lightweight listener observes interactions across the page. When a visitor clicks a tracked element, the dispatcher captures context—such as target URLs, outbound link indicators, and component location—and packages it into an immutable payload pushed to window.dataLayer.

The published specification for this payload is maintained right in this site’s public schema repository at /schema/interaction.json (v1.0.0). When you click the link above, the client dispatcher packages that interaction into this contract:

{
  "$schema": "/schema/interaction.json",
  "schema_version": "1.0.0",
  "event": "cta_click",
  "event_id": "js_1726910400000_a1b2c3d",
  "event_time": 1726910400,
  "interaction": {
    "component": "home_field_notes",
    "label": "view_all_notes",
    "position": null,
    "section_id": "field_notes",
    "text": "View all →",
    "target_url": "https://justinsumner.dev/notes",
    "is_outbound": false,
    "state": null
  },
  "context": {
    "page_path": "/",
    "page_title": "Justin Sumner",
    "referrer": null
  }
}

• Clean Namespacing — Core UI metadata lives under a validated domain object (interaction), preserving custom dimension quotas in GA4. An optional context bag provides an escape hatch for rich component or environment states without cluttering baseline reporting.
• Deterministic Attribution — Modern advertising platforms require an integer Unix timestamp and a unique interaction token to match client and server signals. Generating event_id and event_time at the moment of click ensures every key action is immediately ready for server-side conversion APIs.
• Inspectable Under the Hood — If you open DevTools right now on this page, you can type dataLayer into the console to inspect the live event pipeline, or check __telemetry.schema to trace the data contract definition.

You might ask why we push this payload to window.dataLayer instead of maintaining our own custom global array or event bus.

The choice comes down to pragmatic engineering. dataLayer is the established lingua franca of modern marketing and web analytics stacks. It plays exceptionally well with Google Tag Manager, GA4, and downstream server containers without fighting existing campus workflows. Inventing a proprietary array would add unnecessary friction for very little architectural upside at this stage.

Other modern customer data platforms take a different approach—RudderStack, for instance, uses its own client-side SDK and array (rudderanalytics), as do tools like Segment or Snowplow. But because our data contract lives cleanly across Layer 1 and Layer 2, the underlying model remains completely portable. If the university ever decided to route telemetry through RudderStack or an internal message queue, our UI components and markup wouldn’t change at all. Only the dispatcher’s final handoff at the end of Layer 2 would update.

Beyond Clicks — Semantic Milestones and Section Visibility

A common challenge in digital marketing and content strategy is measuring reading depth on long-form publications. Historically, teams reached for crude scroll depth triggers that fired at 25%, 50%, 75%, or 90% of the page.

That conventional approach has two serious flaws:

1. Geometry Over Semantics — A 50% scroll on a smartphone might land in the middle of a code snippet, while on an ultrawide desktop monitor it lands past the conclusion. Percentages measure screen height, not reader comprehension. Rapid fling-scrolling also inflates “engagement” metrics for visitors who never actually stopped to read.
2. Main-Thread Friction — Attaching frequent scroll listeners directly in the browser risks degrading Interaction to Next Paint (INP) and dragging down Core Web Vitals.

Instead of measuring raw scroll geometry, our contract captures semantic milestones using the browser’s native IntersectionObserver.

The client dispatcher watches key content landmarks—such as section headings and conclusion blocks. When a reader dwells on a section for at least one second, the observer fires a clean, deduplicated section_view event completely off the main thread:

{
  "$schema": "/schema/interaction.json",
  "schema_version": "1.0.0",
  "event": "section_view",
  "event_id": "js_1726910400000_f8e2a1b",
  "event_time": 1726910400,
  "interaction": {
    "component": "note_section",
    "label": "beyond_clicks_semantic_milestones",
    "position": 3,
    "section_id": "beyond-clicks--semantic-milestones",
    "text": "Beyond Clicks — Semantic Milestones and Section Visibility",
    "target_url": null,
    "is_outbound": false,
    "state": "visible"
  },
  "context": {
    "page_path": "/notes/moving-beyond-the-pixel-swamp",
    "page_title": "Moving Beyond the Pixel Swamp | Justin Sumner",
    "referrer": null
  }
}

By capturing section_view milestones alongside clicks, content strategists can correlate which specific sections of an article or academic curriculum page actively drive subsequent application inquiries or recruiter clicks—turning passive reading into actionable editorial intelligence.

Layer 3 — The Server Gateway

Instead of loading third-party vendor pixels directly inside the visitor’s browser, web hits route to a first-party collection subdomain (such as data.justinsumner.dev) running Server-side Google Tag Manager (sGTM).

This server gateway provides major wins for both marketing partners and platform engineers.

• Faster Pages and Better UX — Third-party script bloat disappears from the browser. The visitor’s device only emits one clean stream of first-party JSON over HTTPS, keeping Core Web Vitals in the green.
• Stronger Student and Visitor Privacy — An active gateway sits between visitors and external platforms. Any unintended personal information (such as email addresses or search parameters) is scrubbed or hashed before data leaves institutional infrastructure.
• Resilient Campaign Measurement — Because telemetry routes through our own first-party subdomain, requests are far less vulnerable to client-side ad blockers, tracking prevention, or third-party cookie restrictions. Marketing teams get complete, accurate data without gaps.

Layer 4 — Downstream Syndication

Once verified data arrives at the server gateway, the container syndicates events to partner platforms through official server-to-server REST APIs.

• Google Analytics 4 & BigQuery — Clean event parameters map directly to custom dimensions, feeding long-term institutional reporting and enrollment predictive modeling.
• Marketing Conversion APIs (Meta CAPI, Snap, TikTok) — High-intent interactions (such as contacting an admissions advisor or starting an application) map server-to-server to standard conversion actions (Lead, Contact). Because the payload includes the matching event_id, ad platforms deduplicate hits accurately and optimize campaign delivery.

Upstream Truth Versus Downstream Valuation

A foundational principle in this architecture is keeping objective interaction facts separate from business valuation.

In older setups, teams sometimes tried to assign arbitrary monetary values directly in the HTML tag (such as tagging a brochure download as worth $50). But business value is an analytical hypothesis that evolves over time. An out-of-state prospective student clicking an admissions link represents different enrollment revenue than a returning graduate student, even though both click the exact same button.

By capturing only the objective fact of the interaction at the DOM layer, our marketing analysts, data science teams, and institutional researchers can refine scoring models dynamically downstream in BigQuery or dbt. If marketing leadership updates its recruitment attribution weighting midway through a cycle, historical figures update immediately without requiring anyone to edit web templates or push new code.

Formalizing Campaign Intake and Expiration Dates

A robust technical architecture is only as dependable as the operational process supporting it.

In older workflows, tracking requests often arrived informally—a quick message or forwarded email asking to “drop this pixel on the financial aid page for a couple of weeks.” The immediate request would get fulfilled, but without a formal record or end date, that tag would quietly linger in the container for three years, continuing to execute long after the recruitment cycle ended and the agency contract expired.

To build a sustainable pipeline, we formalized tracking requests into a structured ticketing workflow. Instead of passing around raw JavaScript snippets, marketing teams and agency partners submit an integration request that captures key governance parameters upfront:

• Campaign Objective and Owner — Identifying the primary campus stakeholder, the partner agency, and the business goals of the campaign.
• Event Menu Selection — Picking from verified, pre-existing interactions (like cta_click on application links or program inquiries) rather than inventing ad-hoc page triggers.
• Target Conversion Endpoints — Defining the destination API (such as Meta Conversions API or Google Ads) and the specific conversion action.
• Mandatory Campaign Expiration Dates — Every marketing campaign has a flight window. By capturing an explicit start and end date in the ticket, server-side routes can be scheduled to activate and automatically sunset.

Requiring an expiration date eliminates “zombie tags” entirely. When a spring undergraduate push concludes on May 1st, the server mapping turns off cleanly. Campus web infrastructure stays pristine, data pipelines stay clutter-free, and future audit logs show exactly who requested what, where data flowed, and when it was decommissioned.

A Win-Win Partnership for Campus Digital Teams

Shifting to an event API and a structured intake process turns what used to be a source of operational friction into a genuine collaboration between campus web developers and marketing colleagues.

When a marketing team prepares a new campaign, the conversation is no longer about scrambling to place fragile browser scripts before a Friday launch. Instead, it sounds like this—

“Here is our shared University Event Menu. We already track calls to action, program exploration, navigation clicks, and application steps across all campus platforms. Which verified events represent your campaign KPIs? We’ll map them directly in the server gateway to your ad platform conversion endpoints and schedule the syndication to match your campaign flight dates.”

Marketing teams get clean, deduplicated attribution data they can trust to optimize ad spend. Web platform engineers protect Core Web Vitals, maintain clean codebases, and keep container clutter from piling up. And most importantly, prospective students experience a fast, respectful, and secure digital environment as they navigate their journey into higher education.

Looking ahead, there is also an intriguing architectural question—what happens when institutional interactions move beyond the user interface?

Today, our data contract is deliberately coupled to physical DOM interactions like clicks, submissions, and visual component states. But as campus web architecture decentralizes into headless APIs, conversational assistants, and autonomous AI agents querying university systems directly, human clicks on visual buttons won’t be the only way students interact with campus services.

How does an institutional data contract adapt when an agent initiates an advising inquiry through an API, or when a background service validates prerequisite eligibility without a human ever touching a web page?

Extending this contract from physical UI elements into headless services and agentic workflows is the natural next frontier. But by creating a disciplined, governed event boundary today, we’ve built the foundation for whatever interface comes next.