Adobe Target Developer
Adobe Target is the most implementation-heavy of the major platforms, because it is an enterprise personalisation system rather than only a testing tool. Getting value from it depends on decisions made in code: how at.js or the Web SDK is deployed, how Views are triggered in a single-page application, what profile scripts compute, and how audiences are actually resolved. That is the work we do.
CRO strategy, design and development across Shopify, WordPress, Convert, Optimizely, VWO and Adobe Target.
Does this sound familiar?
These are the situations teams actually describe when they get in touch about this, not a generic list of pain points.
at.js is loaded asynchronously without the prehiding snippet
Adobe documents a prehiding snippet for asynchronous at.js deployments specifically to prevent flicker while content is being fetched. Deployments that skip it, often because at.js was added through a tag manager, flash the default experience on every personalised page.
The SPA has no Views, so the VEC cannot be used
On a single-page application, the Visual Experience Composer depends on adobe.target.triggerView() being called when a view loads or a component re-renders. Without those calls there is nothing for a VEC activity to attach to, and the team concludes Target does not work on their stack.
triggerView is called in the wrong place
Called too early, before the view exists; called on every render, producing duplicate view notifications; or called outside the resolution of the getOffers() promise, so ordering is wrong. All three produce intermittent, hard-to-reproduce failures.
Profile scripts are doing work nobody can audit
Profile scripts are server-side JavaScript evaluated in Target and fed into the Profile Store. They are powerful and almost never documented. Accumulated over years, they silently drive audience membership that nobody on the current team can explain.
The at.js to Web SDK migration is half done
Organisations moving Target onto the Platform Web SDK frequently end up with both paths live on different templates, audiences and profile scripts that behave differently on each, and results that cannot be compared.
What is included
Scope stated as specific outputs rather than as adjectives.
- at.js 2.x implementation and configuration review, including the prehiding snippet where loading is asynchronous
- Adobe Experience Platform Web SDK (alloy) implementation for Target, where that is the direction
- Single-page-application support: Views implemented with
adobe.target.triggerView(), called at the right point in the render lifecycle - Custom offer development in HTML, CSS and JavaScript for VEC and form-based activities
- Form-based Experience Composer work where the VEC cannot reach the surface
- Server-side and hybrid delivery using
getOffers()andapplyOffers()where the decision must be made away from the browser sendNotifications()implementation where impressions have to be reported explicitly- Audience configuration, including profile scripts, profile attributes and Audience Library audiences
- A/B Test, Experience Targeting, Multivariate and Automated Personalization activity setup
- mbox and delivery debugging, including trace-based diagnosis of why a visitor did or did not qualify
- Documentation of existing profile scripts and audiences, usually the highest-value first deliverable on an inherited account
- Full pre-launch QA and post-launch validation
How the work runs
- 1
Document the deployment before changing it
Which library is delivering Target, how it is loaded, whether prehiding is in place, what profile scripts exist and what they compute. On an inherited enterprise account this is most of the work and all of the risk.
- 2
Make the application composable
Where the front end is client-rendered, Views are implemented with
triggerView()at the right points so the VEC becomes usable by the people who are supposed to use it, meaning marketers rather than developers. - 3
Build the activity
Offers developed as code where the VEC cannot express the change, with delivery chosen deliberately between client-side, server-side and hybrid.
- 4
Verify qualification, not just rendering
In Target the hard question is rarely whether the offer renders. It is whether the right visitor qualified. That is verified with delivery traces against real audience conditions.
- 5
QA and launch
Full pre-launch matrix plus a flicker check appropriate to the loading mode, then live-traffic validation.
Who this is for
Enterprise teams in the Adobe stack
Target rarely stands alone. It sits alongside Analytics, Audience Manager and increasingly the Experience Platform, and implementation decisions have to account for all of them.
Agencies and consultancies delivering into Adobe accounts
You need someone who can work inside an existing at.js or Web SDK deployment without destabilising it.
Teams whose SPA has stalled their Target programme
This is the single most common reason we are called about Target, and it is almost always about Views.
Organisations mid-migration to the Web SDK
Two delivery paths live at once is a specific and solvable problem, but not one to leave running.
Adobe Target surface we work in
Named specifically, because “modern tooling” tells a buyer nothing.
- at.js 2.x
- Adobe Experience Platform Web SDK (alloy) for Target delivery
- Visual Experience Composer (VEC) and SPA VEC
- Form-based Experience Composer
adobe.target.triggerView(),getOffers(),applyOffers(),sendNotifications()- Views and mboxes, including
target-global-mbox - Profile scripts, profile attributes and the Profile Store
- Audience Library, including audiences shared from Adobe Analytics and Audience Manager
- Prehiding snippet for asynchronous deployments
- Adobe Experience Platform Tags for deployment
- Activity types: A/B Test, Experience Targeting, Multivariate, Automated Personalization
How this gets checked
Every engagement carries a QA pass. It is written down so that “QA done” means something specific.
- Prehiding verified where at.js is loaded asynchronously; flicker measured on a throttled connection
- View notifications confirmed firing once per view, not once per render
- Offer verified after client-side navigation and after returning to a previously visited view
- Audience qualification confirmed by delivery trace, from qualifying and non-qualifying profiles
- Profile script behaviour verified against expected values rather than assumed
- Impression and conversion reporting reconciled with Adobe Analytics where integrated
- Activity confirmed to deactivate cleanly with no residual DOM change
Ways to work together
The commercial shape is chosen after we know the scope, not before.
Dedicated partnership
Reserved capacity for a steady pipeline of work.
Flexible hours
Draw down specialist time as the work arrives.
Project engagement
A defined scope, owned end to end.
All three are described in full under engagement models.
Questions people ask before buying this
Adobe Target documentation
Platform behaviour described on this page was checked against the vendor’s own current documentation. Verify against these before relying on any of it, because vendors change APIs.
Services on this platform
Other experimentation platforms
Further reading
Hire an Adobe Target Developer
Tell us what is blocked: a SPA that Target cannot see, an activity that flickers, or a deployment nobody has documented. We will start with what is actually there.