Dynamic Yield developer for hire

Case studies on Dynamic Yield

• Bestsellers carousel: homepage social proof (Avon) , results pending

Real work on Dynamic Yield

On the Avon site I built a homepage bestsellers carousel as a social proof test through Dynamic Yield: a 19 product carousel injected above the existing homepage modules, with a desktop variant selector dropdown, a mobile bottom sheet variant picker, and inline add to bag that submits through the host's own cart service rather than a separate cart of its own. Impression events were visibility gated on both control and variant so exposure measurement stayed consistent across arms. The full write up is in the bestsellers carousel case study.

How a build fits into Dynamic Yield

Most of my Dynamic Yield work is a Custom Code campaign, where each variation has its own HTML, CSS and JS tabs. I write the variant outside the platform, paste the built code into those tabs, and set the trigger to match how the target element arrives. Page Load suits server rendered markup. Element load, one of the advanced triggers and keyed to a CSS selector, suits a module that renders later. The Event trigger suits something that only exists after a user action.

Targeting gets the same care as the code. Dynamic Yield's Custom Code campaign documentation says a campaign with no targeting conditions runs on every page of the site, so I never leave that step blank, and I set frequency (once per pageview, per session, per user) to what the hypothesis needs rather than the default.

Before I build, I check the page context. Dynamic Yield expects DY.recommendationContext to be set in the head of every page, before api_dynamic.js and api_static.js load, with the page type in capitals (HOMEPAGE, CATEGORY, PRODUCT, CART, OTHER) and product pages passing a SKU that matches the product feed. A wrong page type or SKU feeds the wrong context to everything built on it, so it is cheaper to find at intake than after a week of traffic. The rules are in Dynamic Yield's page context reference.

What to watch for on Dynamic Yield

Custom Code runs once. Dynamic Yield runs a Custom Code campaign when its trigger fires and does not keep evaluating it. Whatever it injected stays on the page even after the context changes and the campaign no longer matches. On a single page app that means a carousel built for the homepage can still be there on a product page. I write my own teardown for each variant, and where a campaign has to launch again on every screen change I use the campaign's Serve on Every SPA Event setting, which relies on a pageview being reported on each screen change.

Route changes are detected from a narrow set of signals. According to Dynamic Yield's context based page detection docs, the script notices History API and hashchange URL changes, title changes and edits to DY.recommendationContext, and it ignores query string changes. A filtered listing page that only changes its query string is therefore still the same page to Dynamic Yield, so I check that behaviour on the real site before relying on it for targeting.

Waiting for elements has a platform helper. DYO.waitForElement takes a selector, a callback, a minimum element count, an interval and a retry limit. The retry limit defaults to infinity, so I always pass one. A variant that polls forever on a page where its target never renders is still costing the page long after anyone would notice.

// Custom Code campaign, JS tab. Checks every 100ms, gives up after 50 tries.
DYO.waitForElement(".home-modules", function () {
  if (document.querySelector("[data-cro-bestsellers]")) return; // already mounted
  document.querySelector(".home-modules").insertAdjacentHTML(
    "beforebegin",
    '<section data-cro-bestsellers aria-label="Bestsellers"></section>'
  );
}, 1, 100, 50);

Events feed more than the report. Dynamic Yield uses events for optimisation goals, affinity profiles and recommendations, so a variant that adds to cart its own way can quietly stop the site's normal add to cart reporting. The Avon carousel, for example, submitted through the host's own cart service. For interactions the site does not already report, I fire a custom event with DY.API("event", { name, properties }), keep the properties flat (strings, numbers, booleans) because nested properties cannot be used in targeting, and remember that some accented characters are read as their base letter when naming events on non English sites.

Load order matters for flicker. Dynamic Yield's script implementation guide asks for the two scripts to load synchronously, straight after the opening head tag, and not through a tag manager, to avoid flicker. When a site loads them through a tag manager, I raise it before the build, because no amount of care in the variant code makes up for it.

The code that does not change between platforms

Every variant also gets my usual tool neutral engineering: activation that follows single page app routes, anti-flicker limited to what the variant touches, framework inputs the app notices, waits for late markup, and screen reader support. My general A/B testing page covers it, and the guides on flicker and accessible variants go deeper.

How pricing works

Submit a brief and you get an hour estimate back within one UK business day, with a total you approve before any work starts. A single test usually takes between 2 and 20 build hours: a copy or layout change sits near the bottom of that range, a new component or a multi step flow near the top. Regular volume earns a discounted rate, and there is no lock-in: one-off builds are as welcome as a weekly commitment.