Experience Lab was born out of frustration. Every time a marketing team wanted to test a popup — a different trigger, a new headline, a quick exit-intent offer — they had to open a ticket, wait for a developer, and burn two days on something that should take two minutes.

So we built Experience Lab: a free, no-login tool that generates production-ready experimentation custom code from a simple form. No build step. No staging environment. No invoice.

What it does

Experience Lab generates JavaScript you paste directly into the Adobe Target Visual Experience Composer Custom Code editor. The generated script handles everything — modal display, trigger logic (page load, exit intent, scroll depth, idle, click, back button), frequency capping, styling, accessibility, and now email capture with direct platform integrations.

Who it's for

Marketing teams, CRO practitioners, growth hackers, and anyone running A/B tests or personalization experiments. If you've ever waited on a developer to change a modal trigger or tweak a CTA, Experience Lab is for you.

Pricing

Experience Lab is free during early access. We're building toward a sustainable paid model — when that changes, existing users will hear about it first and be treated fairly.

Get in touch

Have feedback, a feature request, or just want to say hi? We'd love to hear from you. Find us at hello@experiencelab.app.

What we collect

Experience Lab is a client-side tool. Everything you type into the form — headlines, URLs, colors, trigger settings — stays in your browser. We do not transmit your form inputs to any server. We do not store them. We do not log them.

Cookies & local storage

Experience Lab uses your browser's localStorage only to remember your light/dark mode preference. No tracking cookies. No analytics cookies. No cross-site identifiers.

Analytics

We may use privacy-respecting, cookieless page-view analytics (such as Plausible or Fathom) to understand aggregate traffic. These tools do not track individual users, do not use cookies, and are not used for advertising.

Advertising

Experience Lab displays third-party advertisements to support the free service. Ad networks may set their own cookies and collect data according to their own privacy policies. You can opt out of personalised advertising via Your Online Choices or your browser's ad-blocking settings.

Third-party integrations

When you configure an email platform integration (Klaviyo, Mailchimp, HubSpot, etc.) and generate a script, the resulting code runs on your website — not ours. Any data submitted through that modal goes directly to the platform you configured. Experience Lab never receives or stores email addresses collected by your modals.

Children

Experience Lab is not directed at children under 13. We do not knowingly collect any personal information from children.

Changes

If we make material changes to this policy, we'll update the date at the top of this page. Continued use of Experience Lab after changes constitutes acceptance.

Contact

Questions? Email us at hello@experiencelab.app.

1. Acceptance

By using Experience Lab ("the Service"), you agree to these Terms of Service. If you do not agree, please do not use the Service.

2. What Experience Lab provides

Experience Lab is a free, browser-based code generation tool that creates JavaScript snippets for use with Adobe Target's Visual Experience Composer. The Service is provided "as is" without warranty of any kind.

3. Your responsibilities

You are responsible for the code you generate and deploy. You must ensure that any modal, email capture, or user-facing experience you create with Experience Lab complies with applicable laws — including GDPR, CCPA, CAN-SPAM, and any other regulations relevant to your jurisdiction and audience.

You must obtain valid consent before collecting email addresses or other personal data from visitors, and you must honour opt-out and deletion requests in accordance with applicable law.

4. Acceptable use

You may not use Experience Lab to generate code that is deceptive, malicious, or designed to harm users. You may not use the Service to harvest personal data in violation of privacy laws or platform policies.

5. No affiliation with Adobe

Experience Lab is an independent tool and is not affiliated with, endorsed by, or sponsored by Adobe Systems Incorporated. "Adobe Target" and "VEC" are trademarks of Adobe Systems Incorporated.

6. Disclaimer of warranties

The Service is provided without warranties of any kind, express or implied. We do not warrant that the generated code will function correctly in all environments, browsers, or Adobe Target configurations.

7. Limitation of liability

To the fullest extent permitted by law, Experience Lab and its operators shall not be liable for any indirect, incidental, or consequential damages arising from your use of the Service or the code it generates.

8. Changes to the Service

We reserve the right to modify, suspend, or discontinue the Service at any time. We may introduce paid plans in the future. We will provide reasonable notice before removing features that are currently free.

9. Governing law

These Terms are governed by the laws of the jurisdiction in which Experience Lab operates, without regard to conflict of law principles.

10. Contact

Questions about these Terms? Email hello@experiencelab.app.

Overview

Experience Lab is a browser-based code generator. You fill in a form, click Generate, and get a self-contained JavaScript snippet ready to paste into Adobe Target's Visual Experience Composer (VEC) Custom Code editor. No server, no account, no dependencies.

The generated script is a single IIFE (Immediately Invoked Function Expression) that runs entirely in the visitor's browser. It creates the modal DOM, injects scoped styles, handles trigger logic, enforces frequency rules, and — for email capture modals — submits to your chosen platform.

Modal types

Standard modal — displays a headline, body copy, and a CTA button or link. Ideal for promotions, announcements, offers, and content gates.

Email capture modal — adds an email input field and submit button. On submission, validates the email client-side and posts it directly to your configured email platform via XHR. No Experience Lab server is ever involved in the data flow.

Form sections

Content — sets the modal type, headline (with text alignment), body copy (with text alignment), CTA label and URL (standard) or email placeholder, submit label, and success message (email capture). Also sets the dismiss button text and style.

Image — optionally adds an image to the modal. Source options: upload a file (encoded as base64, no hosting needed), reference an external URL, or generate a QR code from any URL. Control position (8 placement slots), alignment (left / center / right), width, alt text, and whether the image is clickable with its own destination URL.

Campaign Tracking — optionally appends UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) to your CTA link, image click URL, or both. Applied at generate time so the baked-in URLs always carry the correct attribution.

Trigger — determines when the modal fires. Options: Page Load (with optional delay), Exit Intent, Scroll Depth, User Idle, Element Click, Back Button, and Custom JS Event.

Frequency — controls how often the modal appears per visitor. Rules are stored in localStorage keyed to the page URL. Options range from Always Show through to complex combinations like N times over a rolling window or conditional profile attribute checks.

Styling — sets modal width, border radius, CTA type, button colour, text colours, font sizes, and close button position. A live preview updates in real time as you type.

Live preview

The center panel renders a live preview of the modal as you configure it. It reflects content, text alignment, colours, font sizes, modal type, and image placement — including the email input in email capture mode. The preview is a pure HTML/CSS mock; it does not execute the generated trigger or frequency logic.

Images

Any modal type can include an image — a logo, promotional graphic, product shot, or QR code. Choose a source: Upload encodes the file as base64 directly into the script (no hosting needed); URL references an externally hosted image; QR Code auto-generates a scannable code from any URL via the Google Charts API.

Eight placement positions are available: above headline, below headline, float left, float right, above CTA, below CTA, bottom of modal (below the dismiss link). Alignment (left / center / right) applies to all positions. Images can optionally be made clickable with a dedicated destination URL, independent of the main CTA.

Uploaded images are encoded as base64 data URLs and embedded in the script. Keep promotional images under ~200 KB for best performance inside Adobe Target's VEC.

Campaign tracking (UTM)

Enable Add UTM Parameters to append standard UTM query string parameters to your links at generate time. Parameters are baked into the script so every visitor who clicks the CTA or image carries correct attribution into your analytics platform — no tag manager setup required.

Configure utm_source (e.g. adobe_target), utm_medium (e.g. popup), utm_campaign, and optionally utm_term and utm_content for variant differentiation. Choose whether to apply UTMs to the CTA link only, image click only, or both.

Generating code

Click Generate Script (or press Cmd/Ctrl + Enter) to produce the output. The code appears in the right panel with syntax highlighting. Click Copy to copy it to your clipboard.

The output is wrapped in <script>...</script> tags, matching exactly what Adobe Target's Custom Code editor expects.

Pasting into Adobe Target

In the VEC, select the element where you want the modal to appear (the <body> tag is recommended), choose Edit > Insert After or use the Custom Code option, and paste the generated script. The modal attaches to document.body at runtime so the exact element selection in the VEC matters less than ensuring the script executes on the correct page.

Frequency storage

Frequency state is stored in localStorage under a key derived from the page URL and a counter name. Clearing browser storage resets all frequency caps. The generated script catches localStorage errors (private browsing, storage quota) and falls back to showing the modal rather than silently failing.

Email platform integrations

When the Email Capture modal type is selected, an Email Platform selector appears. Choose your platform and fill in the required credentials (API key, list ID, form ID, etc.). The generated script posts the email address directly from the visitor's browser to the platform's API — Experience Lab never receives or stores any email data.

Supported platforms: Klaviyo, Mailchimp, HubSpot, ActiveCampaign, Brevo, Omnisend, Drip, ConvertKit, Custom Webhook (POST), and Google Tag Manager (dataLayer push).

VEC compatibility

The generated code is hardened for the VEC execution environment, which runs scripts in a sandboxed context that differs from a standard browser page. Compatibility measures include: IIFE wrapping, waitForBody() polling instead of DOMContentLoaded, XHR instead of fetch, explicit top/right/bottom/left instead of inset, margin-bottom instead of gap, vendor-prefixed flexbox, and parentNode.removeChild() instead of .remove().

Generated scripts work in both at.js and Web SDK (Alloy) environments. The Custom Code execution model in the VEC is the same regardless of which library delivers the activity — Experience Lab scripts use waitForBody() polling so they are safe whether at.js or Alloy applies the experience. See the at.js Reference and Web SDK Reference pages for implementation details.

Browser support

Generated scripts target IE11+ and all modern browsers. Vendor-prefixed CSS and pageYOffset fallbacks are included automatically. The Experience Lab interface itself requires a modern browser (Chrome, Firefox, Safari, Edge).

Experience Lab generates code for Adobe Target's Visual Experience Composer. The links below are the most useful parts of Adobe's official documentation for marketers and practitioners working with the VEC and custom code.

Experience Lab is not affiliated with Adobe Systems Incorporated. All links go to Adobe Experience League, Adobe's official documentation portal.

What is a VEC modal?

A VEC modal is a popup overlay injected into a page through Adobe Target's Visual Experience Composer using Custom Code. Because the code runs inside a Target activity, it only appears to the audience segments you define — giving you full control over who sees it, when, and how often, without touching your site's codebase.

Why use Custom Code instead of the VEC editor?

The VEC's drag-and-drop editor is great for changing text and images, but it doesn't support building overlay modals. Custom Code gives you a blank canvas: you inject raw JavaScript that creates the modal DOM, styles it, and handles all interaction logic. Experience Lab writes that JavaScript for you.

Step 1 — Generate your script

Open the Modal Generator, fill in your content, pick a trigger and frequency, configure styling, and click Generate Script. Copy the output.

Optionally add an image (upload, URL, or auto-generated QR code) in any of 8 positions within the modal. Optionally enable Campaign Tracking to bake UTM parameters into your CTA and image click URLs for analytics attribution — no tag manager needed.

Step 2 — Create a Target activity

In Adobe Target, go to Activities > Create Activity and choose the activity type. For a simple modal test, A/B Test works well: one experience with the modal, one control without it. For personalization, use Experience Targeting (XT).

Step 3 — Open the VEC

Enter the URL of the page where the modal should appear. Adobe Target will load the page inside the VEC iframe. If the page doesn't load, you may need to install the experimentation Helper browser extension and disable mixed-content blocking.

Step 4 — Add Custom Code

In the VEC, click on the <body> element (or any element on the page), then select Insert After from the modifications panel. Switch to the Code Editor tab and paste the script generated by Experience Lab. Click Save.

The script tag Experience Lab generates looks like this:

<script>
(function() {
  var CONTENT = { ... };
  var TRIGGER = { ... };
  /* ... modal logic ... */
  waitForBody(arm);
})();
</script>

Step 5 — Set your audience

Define who should see the modal. You can target by geography, device type, traffic source, visitor behaviour, Adobe Analytics segments, or any custom profile attribute. The modal's own frequency logic (set in Experience Lab) then applies on top of Target's audience rules — so a visitor must both match the audience and pass the frequency check before seeing it.

Step 6 — Set your goal

In the Goals & Settings step, define what counts as a conversion. For a standard CTA modal, use a URL conversion goal (the page the CTA links to). If the modal image is clickable with its own URL, you can track that as a separate conversion goal. For an email capture modal, fire a custom mbox or dataLayer event on form submit — Experience Lab's GTM integration option handles the dataLayer push automatically.

Step 7 — QA before activating

Use Target's Activity QA links to preview each experience on a real device without affecting live traffic. Check: modal appears correctly, CTA works, dismiss closes the modal, ESC key works, modal doesn't appear twice on refresh (if frequency is set to once-per-session).

Step 8 — Activate

When QA passes, click Activate. Monitor the activity in Target's reporting view. For email capture modals, check your email platform to confirm submissions are coming through.

Common issues

Modal appears but CTA doesn't work — check that the CTA URL is correct and doesn't contain any URL encoding issues from the Experience Lab form.

Image doesn't appear — if using an external URL, confirm the image is served over https://, publicly accessible, and the server allows cross-origin loading. If using an uploaded file, large base64-encoded images (over ~500 KB) may cause the script to exceed Adobe Target's custom code size limit — compress the image before uploading.

QR code doesn't scan — verify the URL you encoded is correct by scanning the preview in the form before generating. Long URLs with special characters are fine but ensure they're not double-encoded.

UTM parameters not appearing in analytics — UTMs are baked into the generated script at the time you click Generate. If you change the UTM values, regenerate and re-paste the script. Also confirm your analytics platform is reading the utm_ query parameters from the landing page URL, not a referrer header.

Modal doesn't appear at all — check the browser console for errors. Verify that the at.js library is loading on the page before the Target activity fires. If using a page-load trigger with a 0ms delay, try increasing it to 500ms to ensure the DOM is ready.

Modal appears on every page load despite frequency settings — localStorage may be blocked (private browsing mode) or the user has cleared their storage. The generated script falls back to showing the modal in this case.

VEC shows a blank page — install the experimentation Helper Chrome extension and reload. If the page uses strict CSP headers, you may need to temporarily relax them for the VEC domain.

What is at.js?

at.js is Adobe Target's JavaScript implementation library. It must be present on your page for Target activities — including VEC experiments — to function. It handles communication with Target's delivery API, applies experiences, and fires conversion beacons. Experience Lab-generated code runs inside the context established by at.js and does not require any direct calls to it, but understanding at.js helps debug execution timing issues.

at.js versions

at.js 2.x is the current version and is required for Single Page Application (SPA) support. at.js 1.x is legacy. Experience Lab generates code compatible with both, but at.js 2.x is recommended for all new implementations.

Execution order

at.js fires a request to Target's delivery API on page load. When the response is received, it applies the VEC modifications — including your Custom Code — to the DOM. This means your modal script executes after at.js has received and applied the activity. The generated script uses waitForBody() polling to ensure document.body exists before injecting the modal, making it safe regardless of when exactly in the page lifecycle at.js applies the experience.

Key at.js functions

Flicker and anti-flicker

When at.js loads asynchronously, visitors may briefly see the original page before Target applies the experience — this is called flicker. The standard mitigation is a pre-hiding snippet that hides body until at.js has finished rendering, then reveals it. For modal experiments this is less critical (a modal appearing slightly late is acceptable), but if your experiment modifies above-the-fold content you should implement anti-flicker.

The pre-hiding snippet looks like this:

<style>body{opacity:0}</style>
<script>
  window.addEventListener('at-request-succeeded', function() {
    document.body.style.opacity = '1';
  });
  setTimeout(function() {
    document.body.style.opacity = '1';
  }, 3000); /* failsafe */
</script>

at.js settings reference

Key settings configured in Target's Administration panel that affect VEC behaviour:

at.js vs Web SDK — which does your site use?

at.js and Adobe Experience Platform Web SDK (Alloy) are two separate, mutually exclusive implementations of Adobe Target. They cannot coexist on the same page.

at.js is the traditional Target-specific library. It's still widely deployed and is what most VEC implementations use today. If you see at.js in your page source or network requests going to *.tt.omtrdc.net, you're on at.js.

Web SDK (Alloy) is the newer unified library that handles Target, Analytics, Audience Manager, and other Experience Cloud products through a single alloy.js file via the Adobe Edge Network. Requests go to an Edge endpoint like *.adobedc.net. Experience Lab-generated scripts work in both environments — the Custom Code execution model in the VEC is the same regardless of which library delivers the activity.

Not sure which one your site uses? Open DevTools → Network tab → filter by tt.omtrdc (at.js) or interact (Web SDK — requests going to edge.adobedc.net) on page load.

For Web SDK-specific reference, see the Web SDK Reference →

Useful resources

Adobe Target official documentation →
Web SDK Reference →
at.js version history on Experience League ↗
Full at.js function reference on Experience League ↗

What is Web SDK?

Adobe Experience Platform Web SDK — often called Alloy after its JavaScript object name — is the modern replacement for at.js. Rather than one library per Adobe product, Web SDK is a single alloy.js file that handles Adobe Target, Analytics, Audience Manager, Experience Platform, and more through a unified Adobe Edge Network. If your organisation has migrated to Web SDK, at.js is no longer present on your pages.

Web SDK vs at.js — key differences

How Web SDK delivers Target activities

With Web SDK, Target personalization is delivered via the sendEvent command. On page load, Alloy sends a request to the Edge Network which returns personalization decisions (including VEC modifications) alongside Analytics and other data in a single response. The VEC Custom Code is applied in the same way as with at.js — your modal script still executes after Target applies the experience.

Experience Lab-generated scripts use waitForBody() polling, so they are safe in both environments regardless of when the Target activity response arrives.

Key Web SDK commands

Flicker mitigation with Web SDK

Like at.js, asynchronously-loaded Web SDK can cause flicker. The recommended mitigation is to hide the page body until the Edge response is received, using a pre-hiding snippet similar to at.js:

<style>.personalization-container { opacity: 0 }</style>
<script>
  // Reveal after Web SDK applies personalization
  alloy("sendEvent", {
    renderDecisions: true
  }).then(function() {
    document.querySelector('.personalization-container').style.opacity = '1';
  });
</script>

For modal experiments this is less critical — a modal appearing slightly late is acceptable. Anti-flicker matters most when modifying above-the-fold content.

Detecting which library your site uses

Open browser DevTools and check:

Useful resources

at.js Reference →
Adobe Target Docs →
Web SDK Overview on Experience League ↗
Full Web SDK command reference ↗
Web SDK migration guide ↗

This is what we're working on and thinking about. Items move between columns as priorities shift. Nothing here is a commitment — it's a live snapshot of where Experience Lab is headed.

Have a feature request or bug to report? Email us at hello@experiencelab.app.

Found a bug, unexpected output, or something that just doesn't look right? Fill in the form below and we'll look into it. The more detail you include, the faster we can fix it.