Deploy via Adobe Tags (No Adobe Target)

Experience Lab scripts are plain JavaScript — you can run them in Adobe Tags without Adobe Target installed.

Every script Experience Lab generates is self-contained JavaScript. It has no dependency on Adobe Target's at.js library or the VEC — it just reads the DOM and builds a banner, countdown, or modal from scratch. That means you can paste it directly into an Adobe Tags Custom Code action and it will work the same way.

📝What you lose vs. Adobe Target

Without Adobe Target you won't get AT reporting, server-side audience rules, or A/B test traffic splitting. Everything else — all trigger types, frequency modes, placement, styling, and email capture — works exactly as designed.

Setting it up in Adobe Tags

This takes about five minutes if you already have a Tag property published on your site.

Generate your script in Experience Lab

Configure your banner, countdown, or modal exactly as you normally would. Click Generate Script and copy the output.

Strip the script tags before pasting

The generated output is wrapped in <script> … </script> tags. Adobe Tags Custom Code actions expect raw JavaScript only — remove those wrapper tags before pasting. Everything between them is what you need.

Create a new Rule in Adobe Tags

Go to Rules → Add Rule. Name it something descriptive — Experience Lab — Summer Banner. Add an event: Extension = Core, Event Type = DOM Ready.

Why DOM Ready — not Library Loaded

The script injects HTML elements into the page. If it runs at Library Loaded (Page Top), the document.body may not exist yet and the banner will silently fail. DOM Ready fires after the body is available but before images load — the right moment.

Add a Custom Code action

Under Actions, click Add. Choose Extension = Core, Action Type = Custom Code. Paste your script (without the <script> tags) and click Save.

Add conditions to target the right pages

Adobe Tags conditions replace Adobe Target audience rules here. Click + Add under Conditions and use Core → Path or Core → Query String to limit which pages fire the rule. For example, set Path contains /summer-sale to show only on campaign pages.

Save, build, and publish

Save the rule. Go to Publishing Flow, add the rule to your working library, and publish to your Development environment first to test. Once confirmed, promote to Staging and then Production.

AData Collection

Properties › My Site › Rules › Experience Lab — Summer Banner

Events

Core—DOM Ready

Conditions

Core — Pathcontains/summer-sale

Actions

Core—Custom CodeJS

// Experience Lab — Summer Banner

(function(){

var _elId='el-banner-abc1';

// frequency check, DOM inject…

})();

Last saved: just now

Save to LibraryBuild & Publish

Example: what the pasted code looks like

Here's a minimal example of what your Custom Code action will contain. Your actual output will be longer — this just shows the shape.

javascript

// Paste everything between <script> and </script> here.
// Do NOT include the script tags themselves.

(function(){
  var _elId='el-banner-abc123';
  // ... frequency check, DOM injection, event bindings ...
  // All self-contained. No at.js required.
})();

Targeting visitors without Adobe Target audiences

Adobe Target audiences let you show experiences to specific visitor segments. Without Target you can replicate most of this using Adobe Tags conditions and your own data layer.

Scenario	Adobe Tags approach
Specific pages only	Condition → Core → Path contains / starts with
New visitors only	Condition → Core → Cookie — check for absence of your return-visitor cookie
Visitors from a campaign	Condition → Core → Query String contains `utm_campaign=summer`
Mobile only	Condition → Core → Device Type or a Custom Code condition checking `window.innerWidth`
Logged-in users	Condition → Core → Custom Code reading your data layer, e.g. `return !!window.digitalData?.user?.loggedIn`

Frequency modes still work

All Experience Lab frequency modes — once per session, once per day, once per visitor, profile attribute, event-based reset, and until conversion — store their state in localStorage or sessionStoragein the visitor's browser. They don't rely on Adobe Target at all — they work identically when deployed via Adobe Tags.

📝Event-based reset and Until conversion

These two modes require you to fire a reset signal from another page (e.g. a confirmation page). The signal is a window.dataLayer.push or localStorage write. Both work exactly the same whether or not Adobe Target is on the page. See the Advanced Frequency Modes guide for full instructions.

What doesn't work without Adobe Target

Feature	Why
AT reporting (impressions, clicks, conversions)	Requires at.js and an active AT activity to attribute events to
Server-side audience rules (geography, device, profile)	Evaluated by Adobe Target's edge network — not available without AT
A/B traffic splitting	Traffic allocation is managed by Adobe Target — use Tags conditions for manual splits only
Cross-device profile suppression	Requires AT visitor profile attributes (mbox3rdPartyId). localStorage is device-bound.

💡Getting the most out of this approach

Adobe Tags + Experience Lab is a strong combination for rapid campaign deployment when you need personalisation now without waiting for an Adobe Target activity to be set up and approved. For more complex, ongoing personalisation programmes, Adobe Target gives you the analytics and audience tools to scale.

🏷️ Need help setting up the Adobe Tags rules?

We build and audit Adobe Tags implementations — from property setup to rule architecture, data layer design, and publishing workflows. Get it right once.

Talk to us about Adobe Tags