Glassdoor’s Employer Branding Ad is a dynamic ad unit that renders directly in job search results. It pulls live employer data — company logo, aggregate rating, a curated positive review, and key stats — and presents it alongside standard job listings. The goal is to give employers a way to differentiate at the moment a candidate is evaluating options. The unit increased click-through rate by 8x and generated $600,000 in revenue in a single quarter.
My job was to build the creative: the JavaScript bundle responsible for fetching that data and rendering the ad at runtime.
The bundle
The creative loads in a third-party ad context, which imposes hard constraints. Bundle size directly affects load time, and load time affects whether the ad renders before a user scrolls past it. I chose Preact over React for this reason — it covers the component model and rendering we needed at a fraction of the weight. The difference is material when you’re shipping to an ad slot, not a product page.
The bundle fetches the employer’s logo, their current aggregate rating, a selected positive review, and supporting stats — then renders the full unit client-side. The data layer had to be resilient: graceful fallbacks for missing assets, clean error boundaries, and no visible jank during load.
Developer experience
Ad creative development has a particular problem: the ad renders inside a third-party iframe in a real publisher page, so your usual localhost setup tells you almost nothing about how the unit actually behaves in production. I built a development environment specifically designed to close that gap.
The environment fetched real test pages from staging, injecting the local bundle into the page so the ad rendered in its actual context — real layout, real surrounding content, real ad slot dimensions. This meant feedback was accurate from the first iteration, not just from final QA.
Hot reloading via Webpack kept the iteration loop tight. A change to a component or style was reflected in the rendered ad within seconds, without manually rebuilding and reloading a test page. For something with as many visual edge cases as an ad unit — varying logo aspect ratios, long company names, review text of different lengths — fast iteration mattered.
What I’d do differently
The team’s standard approach used Emotion for styling — a runtime CSS-in-JS library. That pattern works well for product UIs but is a poor fit for ad creative: styles exist only as JavaScript and are injected into the DOM at runtime, which means the browser has to parse and execute the bundle before any styles are applied. In an ad context that latency shows up exactly when first impressions matter most.
A better architecture would be a server-side rendered ad with inline CSS. The server renders the HTML with employer data baked in, styles are inlined in the <head>, and the browser can paint the unit on first parse without waiting for JavaScript to execute and inject styles. The bundle becomes a thin enhancement layer rather than the entire rendering pipeline. It’s a more complex server-side setup, but the performance characteristics are meaningfully better for a unit that lives or dies on load speed.