Adobe Target developer for hire

What I actually touch in Adobe Target

Less than most people expect. The test arrives as a single minified script and stylesheet that I paste into the activity as custom code. In Target I set the audiences, the traffic split and the goal, and conversion reporting runs through GA4, or through the client's Adobe Analytics where that is the system of record. Keeping logic out of Target's UI means a publish has fewer moving parts, and your team can read the whole test in one place when they take it over.

When a test needs structured content rather than a DOM change, I use the form based composer. Adobe's docs describe it delivering HTML or JSON offers into custom decision scopes, which were called mboxes before, and JSON offers only work in form based activities and have to be fetched in code. That route suits tests where your own front end should render the variant.

at.js 2.x or the Web SDK: the first thing I check

Adobe Target reaches the page through one of two libraries, and the code I write depends on which one yours loads. On at.js 2.x, offers come from adobe.target.getOffers(), get rendered with adobe.target.applyOffers(), and flicker settings live in window.targetGlobalSettings. On the Experience Platform Web SDK, the same job is alloy("sendEvent") with renderDecisions, or applyPropositions when rendering by hand, and prehiding is the prehidingStyle setting. Adobe keeps a side by side comparison of the two, which I use when a site is partway through a migration and both calls exist in the codebase.

Single page apps and Target Views

On a React, Vue or Next.js site built on at.js 2.x, Target works in Views. Offers for every view are prefetched and cached in one request on page load, and the site calls adobe.target.triggerView() each time a view changes so Target can apply the cached content. If that call is missing, the Visual Experience Composer cannot detect the views, so visual tests on anything after the first view are not possible. I check for it before quoting, and where it is absent I write the router hook your developers need to add.

// at.js 2.x: tell Target the view changed after the route renders
adobe.target.triggerView("checkoutView");

// Re-render a component without counting a new impression
adobe.target.triggerView("checkoutView", { page: false });

Adobe's guidance is to call it once per view, and page: false skips the impression notification when only a component re-renders. On the Web SDK the equivalent is setting web.webPageDetails.viewName on the sendEvent call.

What to watch for with Target's prehiding

When at.js loads asynchronously, Adobe's prehiding snippet sets body {opacity: 0 !important} until Target responds, with a timeout of 3000 milliseconds by default. The at.js setting bodyHiddenStyle also hides the whole body unless you change it. On a slow page that is a blank screen for every visitor, tested or not, and it shows up in LCP. Both accept a narrower selector, so I scope the hide to the containers the activity changes. The lower level getOffer() and applyOffer() calls do no prehiding of their own, so any test built on them brings its own.

The rest of the build

Everything below the platform layer is identical whichever tool runs the test: activation that follows route changes, anti-flicker limited to the changed elements, framework input handling, waiting for late elements, and accessible components. That practice is written up on the A/B test developer page, with detail in stopping A/B test flicker and accessible A/B test variants.

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.