# Dalton Docs — Full Documentation --- # Source: https://docs.getdalton.com/advanced/mcp-server # Dalton MCP Server Connect Dalton to your AI assistant. Once installed, you can ask Claude (or any MCP-compatible AI) to create experiments, list your pages, look up results, and more - all in plain language. ## What is the MCP Server? MCP (Model Context Protocol) is the standard that lets AI assistants talk to external tools. The Dalton MCP server gives your AI assistant a secure, read/write connection to your Dalton account. **Examples of what you can ask:** - *"List the pages I have set up in Dalton."* - *"Create a new experiment on my pricing page that tests a more confident headline."* - *"How is my homepage hero experiment performing?"* - *"Update my brand voice in Dalton — we're shifting from playful to authoritative."* You sign in once with your Dalton account, and the assistant only ever sees the data your account already has access to. ## Server Details | | | |---|---| | **Server URL** | `https://mcp.getdalton.com` | | **Transport** | HTTP | | **Authentication** | Sign in with Dalton (OAuth) | When you connect for the first time, a browser window will open and ask you to log in to Dalton and approve access. That's it — no API keys to copy or environment variables to set. ## Install on Claude Desktop Claude Desktop is the easiest way to get started. ### 1. Open Settings In Claude Desktop, go to **Settings → Connectors → Add custom connector**. ### 2. Add the Dalton Connector Fill in the form: - **Name**: `Dalton` - **URL**: `https://mcp.getdalton.com` Click **Add**. ### 3. Sign In Claude will open a browser window asking you to sign in to Dalton and authorize the connection. Approve it. ### 4. Try It Start a new chat and ask: > *"Use Dalton to list my pages."* Claude will request permission to call the Dalton tools the first time. Approve, and you're live. ::: tip Available on Pro, Team, and Enterprise plans Custom connectors require a paid Claude plan. ::: ## Install on Claude Code Claude Code is Anthropic's CLI for developers. Adding Dalton takes one command. ### 1. Add the Server In your terminal, run: ```bash claude mcp add --transport http dalton https://mcp.getdalton.com ``` ### 2. Sign In Start Claude Code (`claude`) and run: ``` /mcp ``` Select **dalton** from the list and choose **Authenticate**. A browser window will open for you to sign in to Dalton. ### 3. Try It Back in your Claude Code session, ask: > *"Use Dalton to show me how my checkout experiment is performing."* That's it. ## What You Can Do A non-exhaustive list of what the assistant can do on your behalf: | Area | Examples | |------|----------| | **Pages** | List, search, add, remove, and inspect tracked pages | | **Experiments** | Create experiments from scratch or by smart-copying an existing one; list, search, and inspect them | | **Variants** | Add, edit, duplicate, remove, and AI-improve the variants inside an experiment | | **Results** | Pull conversion rates, lift, and statistical significance for any experiment | | **Brand** | View and update your brand voice, audience, and positioning | | **Docs** | Search and read the Dalton product documentation | | **Account** | See who you're logged in as and which customer accounts you have access to | Ask the assistant *"What can you do with Dalton?"* to get a live, up-to-date list. ## Troubleshooting **The assistant says it can't find Dalton tools.** Make sure the connector is enabled in your client's settings, and that you completed the sign-in step. In Claude Code, run `/mcp` and confirm `dalton` shows as **connected**. **Sign-in window didn't open.** Some clients block popups. Check your browser, or look in the client's logs for the authorization URL and open it manually. --- # Source: https://docs.getdalton.com/advanced/multi-language # Multi-Language Dalton works with any language. Each language version of your site is treated as a separate page. ## How It Works Each language URL is a **separate page** in Dalton: 1. **Target each language version separately** - Point one experiment at `/en/pricing` and another at `/fr/tarifs` 2. **Build variants per language** - Each language version gets its own experiment and its own variants 3. **Filter by market** - Use the market filter on the Experiments page to find the right language versions ## Automatic Language Detection When you create experiments, Dalton automatically: - **Detects the page language** and generates variants in that language - **Adapts tone and cultural context** appropriately - **Responds in your prompt language** - prompt in French, get French variants You don't need to configure anything—just add the page and start experimenting. ## Managing Multi-Language Sites **On the Experiments page:** - Group experiments by the pages they target - Filter by market to narrow to one language - Compare performance between languages **Example setup:** | Page | Language | Experiments | |------|----------|-------------| | `example.com/en/pricing` | English | 3 active | | `example.com/fr/tarifs` | French | 2 active | | `example.com/de/preise` | German | 1 active | ::: tip Start with Highest Traffic If 70% of traffic is English, 20% Spanish, 10% French—start with English experiments first, identify what works, then apply learnings to other languages. ::: --- # Source: https://docs.getdalton.com/advanced/multi-page-experiments # Multi-Page Experiments Run the same experiment across multiple pages at once using URL patterns. ## When to Use Multi-Page Multi-page experiments are useful when you have many pages with the same structure: - **Product Detail Pages (PDPs)** - Test the same headline or CTA format across all products - **Category pages** - Test layout changes across all category listings - **Blog posts** - Test content formatting across all articles - **Landing pages** - Test variations across campaign pages with similar structure ## Where the pages are chosen Which pages an experiment runs on is set by its [targeting group](/experiments/targeting): a set of URL rules, reusable across experiments, with a live estimate of the traffic they cover and how long a test on them would take. That page covers the rule operators and how to combine them. This one covers the part that catches people out: what you can safely change once an experiment spans more than one page. ## The Most Important Rule ::: danger Test Elements That Exist on ALL Matched Pages When you edit an element in a multi-page experiment, that change applies to **every page** matching your URL pattern. **The common mistake:** You're on a product page and test the product title or price. But these elements are different on every product page. Dalton shows your test version everywhere—suddenly all products have the same title. **Only test elements that are identical across all pages:** - Navigation headers - CTA button text (not product-specific) - Trust badges - Footer content - Generic section headings ::: ## What Works vs. What Doesn't | Works Well | Doesn't Work | |------------|--------------| | "Add to Cart" button text | Product titles | | "Free shipping" banner | Product prices | | Review section header | Product descriptions | | Trust badges near checkout | Inventory/size selectors | ## Setting Up Multi-Page Experiments 1. **Build the targeting group** - Describe the pages in plain language, or write the rules yourself. See [Targeting Groups](/experiments/targeting) 2. **Check the reach panel** - Confirm the group matches the pages you expect, and that time to results is acceptable 3. **Select an element that exists identically on all pages** - Not product-specific content 4. **Preview on multiple page types** - Check several different URLs that match your rules 5. **Launch** ## Previewing Multi-Page Experiments Before launching: 1. List 3-5 different URLs that match your rules 2. Open the preview for each one 3. Verify the element you're testing exists and looks correct on all of them If the element doesn't exist on some pages, or looks different, narrow your rules or choose a different element. --- # Source: https://docs.getdalton.com/advanced/pixels # Dalton Pixel Installation Guide Installing the **Dalton Pixel** allows you to track conversions, purchases, and custom events directly from your website. This guide explains how to install and use the Dalton Pixel across your site or specific pages. --- ## Installation Overview Dalton Pixel works on any platform (React, Shopify, Webflow, Framer, WordPress, etc.). Installation involves adding a JavaScript snippet to your pages. You can install it: - **Sitewide** – Measure all visitor activity across your entire website - **Per Page** – Track events only on specific landing or checkout pages --- ## Installation Instructions ::: tip Trying to install on a Shopify store? Installation instructions can be found on our Shopify installation guide ::: ### 1. Get Your Pixel Snippet Locate your **unique Pixel snippet** in Dalton under **Connectors → Tracking → Dalton Pixel → Other stores**. --- ### 2. Add to Your Website Paste the following snippet right before the closing `` tag on each page where you want tracking active. ``` html ``` ::: tip Share with Developer If you don’t manage the site code directly, click **"Share with Developer"** in the install panel. This generates a shareable link containing your customer ID and ready-to-install script. ::: --- ### 3. Verify Installation After adding the snippet, go back to **Connectors** and confirm the **Dalton Pixel** row shows as **Installed**, with purchases counted over the last 7 days. --- ## Event Tracking Examples Once the pixel is installed, you can start tracking conversions, purchases, and other key events using Dalton’s JavaScript API. Currently, there are 2 built-in events, but you can always send custom events. ### purchased ```javascript dalton?.fn && dalton.fn.purchased({value: 1, currency: 'eur'}) ``` ### converted ```javascript dalton?.fn && dalton.fn.converted({value: 1, currency: 'eur'}) // or dalton?.fn && dalton.fn.converted() ``` ### custom ```javascript dalton?.fn && dalton.fn.event('my-custom-event', {your: 'event data', here: 1234 }) ``` ### 1. Simple Conversion Use this for basic actions like newsletter signups or button clicks. ```html ``` --- ### 2. Form Submission with Data Pass transaction values or metadata directly into Dalton for precise tracking. ```html ``` --- ### 3. Async Event with API Response Track events after confirming a successful API response. ```html ``` --- # Source: https://docs.getdalton.com/advanced/shopify-pixel # Dalton Pixel for Shopify Add the Dalton Pixel to Shopify as a Custom Pixel so Dalton can track what happens in Shopify's checkout, including purchases. Once it's installed, Dalton automatically tracks: - Product added to cart (`add_to_cart`) - Checkout started (`begin_checkout`) - Checkout completed (`purchase`) ## 1. Add the pixel In your Shopify admin: 1. Go to **Settings → Customer events**. 2. Click **Add custom pixel**. 3. Name it `Dalton Pixel`. 4. Paste the following code into the **Code** editor: ```javascript // DALTON PIXEL — SHOPIFY CUSTOM PIXEL INSTALLATION const customerId = {{customerId}} // Your Dalton customer ID self.dalton = self.dalton || {} self.dalton.analytics = analytics self.dalton.browser = browser self.dalton.init = init const script = document.createElement("script") script.setAttribute("id", "dalton-pixel") script.src = `https://cdn.getdalton.com/pixel/${customerId}.min.js?customer_id=${customerId}` document.head.appendChild(script) ``` 5. Click **Save**. If the code shows `xxxxx` instead of your customer ID, replace it with your Dalton customer ID before saving. ::: tip Replacing an older Dalton pixel? If you already have a Dalton Custom Pixel, replace all of its code with the snippet above and save. ::: ## 2. Connect the pixel 1. In **Settings → Customer events**, open **Custom pixels**. 2. Under **Disconnected**, find `Dalton Pixel` and click **Connect**. 3. Review Shopify's confirmation and click **Connect** again. The regular Dalton storefront script must also be installed so a Dalton session exists before checkout. See the [Dalton Pixel Installation Guide](/advanced/pixels) for the storefront snippet. Do not add that storefront snippet inside the Custom Pixel editor. ## Verify the installation 1. Open the storefront in a new browser session. 2. Add a product to the cart and begin checkout. 3. Complete a test checkout if your store permits it. 4. Confirm that the events appear in the Dalton dashboard with the correct page and session. **Settings → Customer events → Custom pixels** should show `Dalton Pixel` as **Connected**. ## Custom events The events listed at the top of this page are tracked automatically. To track other actions, add these calls to your theme code (for example in a theme snippet or section) on pages where the Dalton storefront script is loaded. Don't add them to the Custom Pixel editor. ```javascript dalton?.fn?.purchased({ value: 49.95, currency: "EUR" }) dalton?.fn?.converted({ value: 10, currency: "EUR" }) dalton?.fn?.event("my_custom_event", { source: "shopify" }) ``` See [Event Tracking Examples](/advanced/pixels#event-tracking-examples) for more examples. ## Disconnect or remove the pixel - To pause tracking, go to **Settings → Customer events → Custom pixels** and click **Disconnect** next to `Dalton Pixel`. - To remove it, click the menu button (≡) on the `Dalton Pixel` row, select **Delete**, and click **Delete** again to confirm. Deleting a Custom Pixel is permanent. ## Shopify resources - [Shopify: Add a custom pixel](https://help.shopify.com/en/manual/promoting-marketing/pixels/custom-pixels/code) - [Shopify: Manage custom pixels](https://help.shopify.com/en/manual/promoting-marketing/pixels/custom-pixels/manage#add-custom-pixel) --- # Source: https://docs.getdalton.com/cro-agent # CRO Agent The CRO Agent scans your store on a schedule and reports the conversion problems it finds. Each one comes with a test already built. ![The CRO Agent](/v2/cro-agent.png) Opportunities come one at a time. Each shows an impact rating, what is going wrong, and a screenshot of it on your site. - **Open test** builds the experiment and opens it in the editor. - **Discard idea** removes it. - **Start custom scan** points the agent at something specific. Nothing launches without you. ## The full report **Read the full report** opens the evidence behind a finding. ![A CRO Agent report](/v2/cro-agent-report.png) You get the observation with links to the pages it came from, the benchmarks and research it compared against, and the metrics behind the impact rating. ## Saved Tests you open but do not launch collect under **Saved**, and appear in [Experiments](/experiments/overview) as drafts. ## Tuning it **Settings → CRO Agent → Custom instructions** tells the agent what to focus on and what to skip: campaigns to ignore, pages mid-redesign, things you will not test. It also reads your [Brand Intelligence](/editor/brand-intelligence) profile. The agent cannot see your margins, stock or internal constraints. Treat its impact estimates as a way to rank ideas, not as a forecast. --- # Source: https://docs.getdalton.com/editor/brand-intelligence # Brand Intelligence To help Dalton create high-quality experiments and content aligned with your brand, you can add additional context in the Brand Intelligence tab. ## Easy setup When you add your site, Dalton runs a full website scan and prefills your brand profile automatically — so there's little to set up by hand. Some fields are filled from the scan and shown for reference: - **Brand description** — what your brand is and what it sells - **Industry & keywords** — your market and the terms that describe it - **Colors & logo** — your visual identity Others are yours to edit and refine: - **Important benefits** — the key selling points Dalton should lean on - **Remarks & guidelines** — extra instructions, do's and don'ts, and anything else that should steer the AI The more accurate this profile, the better Dalton's experiments match your voice and positioning. ## Competitors Add the brands you compete with — up to 10. Dalton uses them as reference points when generating experiments and insights, so suggestions reflect how you stack up in your market. You can add a competitor by name or website. ## Brand Assets Give Dalton deeper context by attaching your own material: - **Upload files** — brand guidelines, style guides, product sheets, or other documents - **Add URLs** — links to pages that describe your brand or products Dalton indexes these assets and draws on them when creating experiments, so generated content stays consistent with your brand. --- # Source: https://docs.getdalton.com/editor/prompting-best-practices # Prompting Best Practices Getting great results from Dalton's AI comes down to how you write your prompts. This guide covers what works, what doesn't, and how to troubleshoot common issues. ## The Golden Rule: Be Specific The AI performs best when you tell it exactly what you want. Vague prompts lead to unpredictable results. | Instead of... | Try... | |--------------|--------| | "Make it better" | "Focus on the time-saving benefit" | | "Make it shorter" | "Make this one sentence" | | "Change the layout" | "Move the reviews section above the product description" | | "Add something here" | "Add a trust badge showing free returns" | | "Improve the CTA" | "Make the button copy action-oriented, starting with a verb" | ## Common Web Design Terms Understanding basic web design terminology helps you write clearer prompts. See [Common Web Design Terms](/editor/prompting-terms) for a complete guide to margin, padding, alignment, and other essential terms. ## Tell the AI What You Want (Not What You Don't) Positive instructions work better than negative ones. | Instead of... | Try... | |--------------|--------| | "Don't make it too long" | "Keep this under 10 words" | | "Remove the fluff" | "Focus only on the main benefit" | | "Don't be too salesy" | "Use a conversational, helpful tone" | | "Avoid jargon" | "Use simple language a beginner would understand" | ## Device-Specific Prompts Dalton can apply changes to specific devices. Add these phrases to your prompt: - **"on mobile only"** - Changes apply only to mobile view - **"on desktop only"** - Changes apply only to desktop view - **"for mobile"** - Same as above **Examples:** - "Center this text on mobile only" - "Make the button full-width on mobile" - "Show a shorter headline on mobile only" ::: tip Check Both Views Always preview both desktop and mobile after making changes, even if you specified a device. This ensures nothing unexpected happened. ::: ## One Change at a Time Complex prompts with multiple instructions often fail. Break them into steps: **Instead of:** > "Reorder these three sections, change the headline to focus on speed, and make the CTA more urgent" **Do this:** 1. "Move the testimonials section above the features" 2. "Change the headline to emphasize how fast setup is" 3. "Make the CTA button copy more urgent" ## Prompts That Work Well **Headlines:** - "Make the headline focus on [specific benefit]" - "Test a question-based headline" - "Make this headline more specific about [outcome]" **CTAs:** - "Start the button text with an action verb" - "Add urgency to the CTA without being pushy" - "Make the button copy benefit-focused instead of action-focused" **Layout:** - "Move [element] above [other element]" - "Add a [trust badge/social proof/urgency indicator] near the CTA" - "Make the [section] more prominent" **Copy:** - "Shorten this to one sentence" - "Add a specific number or statistic" - "Focus on [pain point] instead of [feature]" ## Prompts That Don't Work Some things are outside what the AI can do: - **Dynamic content:** "Change the price" / "Update the inventory count" - **Images:** "Add a product photo" / "Change the hero image" - **Navigation:** "Rearrange the menu items" - **Forms:** "Add a new form field" - **Animations:** "Make this fade in" For these, build the alternative as a separate page rather than as a variant. ## How Dalton Works: Capabilities & Limitations Understanding how Dalton operates helps you write prompts that work within the platform's constraints. ### Two Main Flows Dalton uses two different flows depending on what you're doing: - **Prompting Flow**: Creates new experiments from scratch. You select an element and describe what you want to change or add. Best for new experiments, adding elements, or making initial modifications. - **Improve Flow**: Iterates on existing variants. You can modify the HTML, CSS, or JavaScript of variants you've already created. Best for refining experiments, adjusting styling, or tweaking copy after initial creation. You cannot change the target of the experiment, and for bigger changes, it might be better to start fresh with a more detailed prompt. ::: tip When to Use Each Flow Use **Prompting** to create new experiments or when the experiment generated needs too much work. Use **Improve** when you want to refine an existing variant or you want to create a new one **For both flows you can use the add context button to select extra elements on the page relevant to your experiment (e.g. selecting the user reviews lower on the page for a new social proof element in your hero banner).** ::: ### What Works Dalton can modify your site through a front-end overlay (a JavaScript snippet that runs in the browser). This means it can: - **Text changes**: Headlines, copy, button text, descriptions - **Styling**: Colors, fonts, spacing, borders, backgrounds - **Layout**: Moving elements, reordering sections, changing spacing - **New elements**: Adding trust badges, social proof, banners, sections - **CSS-only animations**: Transitions, hover effects, simple animations - **Simple JavaScript**: Basic interactivity like accordions, tooltips, ... ### What Doesn't Work Because Dalton operates as a front-end overlay, it is hard and often not possible to do the following experiments: - **Dynamic content**: Prices, inventory counts, product names, user-specific data - **Forms**: Adding new form fields or changing form behavior - **Backend logic**: Database changes, server-side processing, API modifications ::: warning Dynamic Content Gotcha If you're testing on product pages or template pages, **never hardcode prices, product names, or reviews**. These must remain dynamic. Always specify in your prompt: "Make sure the price is dynamic, not hardcoded" or "Use the existing product name, don't replace it." ::: ### Technical Constraints Dalton uses `document.querySelector` to target elements via CSS selectors, then applies changes using one of three operations: - **INSERT_BEFORE**: Adds new content before an existing element - **INSERT_AFTER**: Adds new content after an existing element - **REPLACE**: Replaces an existing element with new content The platform works on any website (Shopify, Webflow, custom code) because it operates at the browser level, not the code level. ## Scenario-Specific Guidance Different page types and scenarios require different approaches. Here's how to prompt effectively for common situations: ### Template Pages & Multi-Page Experiments When running experiments across multiple pages (like all product pages or all blog posts): - **Ask for pure styling experiments**: Focus on layout, colors, spacing, and visual hierarchy - **Specify dynamic content requirements upfront**: "Make sure product prices are dynamic, not hardcoded" - **Avoid product-specific content**: Don't ask to add specific product names, reviews, or details that only apply to one product **Example:** > "Add a trust badge above the add-to-cart button. Use the existing product price dynamically—don't hardcode it. Style it to match the page's existing design." ### Product Detail Pages (PDP) Product pages have complex layouts and dynamic content. Be extra careful: - **Never hardcode prices, product names, or reviews**: These are dynamic and product-specific - **Preserve interactivity**: Color swatches, add-to-cart buttons, quantity selectors must continue working - **Handle complex layouts carefully**: PDPs often use flexbox or grid layouts that can break if not handled properly **Example:** > "Add shipping information near the add-to-cart button. Make sure the add-to-cart functionality still works and the price remains dynamic." ### Product Listing Pages (PLP) Collection pages display multiple products. Key considerations: - **Don't replace product cards**: They contain dynamic product data - **Be careful with filters and sorting**: These are interactive and must continue working - **Use JavaScript for card modifications**: If you need to modify cards, use `querySelectorAll` to target all cards **Example:** > "Add a 'New' badge to product cards that are less than 30 days old. Don't replace the cards—just add the badge using JavaScript." ### Interactive Elements When working with interactive elements (buttons, forms, swatches, dropdowns): - **Preserve event handlers**: If replacing a button, proxy the click event to the original - **Hide, don't remove**: Use `opacity: 0` or `visibility: hidden` on original elements, never delete them - **Test functionality**: Always verify that interactions still work after your changes **Example:** > "Replace the add-to-cart button with a larger, more prominent version. Make sure clicking it still adds items to the cart by proxying the click event to the original button." ### Complex Layouts (Flexbox & Grid) Modern sites use flexbox and grid for layouts. When prompting: - **Respect existing layout structure**: Don't break the container's layout system - **Consider responsive behavior**: Layouts change on mobile vs desktop - **Use insertion strategies**: Sometimes it's better to insert after and hide the original, rather than replacing **Example:** > "Move the reviews section above the product description. Make sure this works on both mobile and desktop without breaking the page layout." ## When Prompts Fail If your prompt keeps failing or producing errors: 1. **Check if the element is dynamic** - Prices, inventory, size selectors can't be modified 2. **Try selecting a parent element** - Sometimes the specific element is inside a component the AI can't access 3. **Simplify the prompt** - Remove any complexity and try one change 4. **Check for iframes** - Content inside iframes (like embedded forms) can't be edited See [Troubleshooting](/faq/troubleshooting) for more detailed solutions. ## Iterating on Results Don't expect perfection on the first try. The best experiments come from iteration: 1. Start with a simple, specific prompt 2. Preview the result 3. If not quite right, create a new variant with a refined prompt 4. Compare variants to find what works ::: tip Undo or Start Fresh If a variant doesn't look right, use undo to revert changes, or delete it and create a new one with a better prompt. ::: ## CRO-Optimized Example Prompts See [CRO Example Prompts](/editor/prompting-examples) for 8 real-world example prompts covering trust signals, CTA optimization, social proof, urgency messaging, section reordering, SaaS optimization, pricing tables, and mobile-specific improvements. Each example includes the prompt text, CRO hypothesis, and important considerations. --- # Source: https://docs.getdalton.com/editor/prompting-examples # CRO-Optimized Example Prompts Here are real-world example prompts for common CRO experiments. Each example includes the prompt text, the hypothesis behind it, and important considerations. ## 1. Adding Trust Signals to Product Pages **Prompt:** > "Add trust badges (free shipping, secure checkout, money-back guarantee) directly above the add-to-cart button. Style them to be subtle but visible, using small icons with text. Make sure the add-to-cart button functionality is preserved and the product price remains dynamic." **CRO Hypothesis:** Trust signals near the primary CTA reduce purchase anxiety and increase conversion rates. Research shows trust badges within 200px of checkout CTAs can increase conversions by 7-15%. **Considerations:** - Ensure the price is dynamic, not hardcoded - Preserve add-to-cart button functionality - Test on mobile to ensure badges don't clutter the interface ## 2. Optimizing CTA Button Copy and Styling **Prompt:** > "Replace the main call-to-action button in the hero section. Change the text from 'Learn More' to 'Start Your Free Trial' and make it use the primary brand color (the blue from the logo). Increase the button size slightly and add a subtle hover effect that makes it slightly darker. Ensure it links to the same destination." **CRO Hypothesis:** Action-oriented, benefit-focused CTAs with clear value propositions (like "free trial") convert better than vague CTAs. Visual prominence through color and size draws attention to the primary action. **Considerations:** - Proxy click events if replacing an interactive button - Match the brand's existing color palette - Test button contrast for accessibility ## 3. Adding Social Proof Near CTAs **Prompt:** > "Add a social proof section immediately after the hero section. Include a headline like 'Join 10,000+ happy customers' and display 3-4 customer logos in a row. Style it to be clean and professional, matching the page's existing design. On mobile, stack the logos vertically." **CRO Hypothesis:** Social proof (customer counts, logos, testimonials) reduces perceived risk and builds credibility. Placing it early on the page, near the hero, leverages the goal-gradient effect—users feel they're joining a community. **Considerations:** - Use actual customer counts if available, or use placeholders like "[CUSTOMER_COUNT]" - Ensure logos are properly sized and don't break on mobile - Don't invent customer names or companies ## 4. Adding Urgency/Scarcity Messaging **Prompt:** > "Add a limited-time offer banner above the pricing section. Display text like 'Limited time: Save 20% on annual plans' with a countdown timer showing days remaining. Style it with a subtle background color that matches the brand, and make it dismissible with a small X button. Only show this if there's evidence of a current promotion on the page." **CRO Hypothesis:** Scarcity and urgency messaging can increase conversions by creating FOMO (fear of missing out), but only when authentic. Loss aversion makes users act faster when they perceive limited availability. **Considerations:** - **Only use if there's actual evidence of a promotion**—never invent discounts or sale prices - Ensure the countdown timer is functional (may require JavaScript) - Make it dismissible to avoid annoying returning visitors - Test that it doesn't conflict with existing promotional messaging ## 5. Reordering Sections for Better Hierarchy **Prompt:** > "Move the customer testimonials section to appear immediately after the hero section, before the features section. On mobile, ensure the testimonials are still readable and don't create too much scrolling before the main CTA." **CRO Hypothesis:** Placing social proof and trust signals early (above the fold or immediately after the hero) builds credibility before users evaluate features. This follows the principle of establishing trust before asking for commitment. **Considerations:** - Test on both mobile and desktop to ensure layout doesn't break - Consider the page's existing flexbox or grid structure - Ensure the section maintains its styling and functionality after moving ## 6. Optimizing SaaS Landing Page Hero **Prompt:** > "Redesign the hero section headline to focus on the primary pain point our ideal customer faces. Change the subheadline to be more benefit-focused, emphasizing time savings. Make the primary CTA button more prominent by increasing its size and using a contrasting color. Add a short value proposition line directly above the CTA." **CRO Hypothesis:** Headlines that address specific pain points resonate more with target audiences. Benefit-focused messaging (time savings, efficiency) converts better than feature-focused messaging. Prominent CTAs with clear value props reduce friction. **Considerations:** - Maintain brand voice and tone - Ensure the CTA remains functional - Test headline length on mobile (shorter may be needed) - Keep the value proposition concise (one sentence) ## 7. Emphasizing Preferred Plan in Pricing Table **Prompt:** > "Make the middle pricing tier (the 'Professional' plan) more visually prominent by increasing its size slightly, adding a subtle border or background color, and placing a 'Most Popular' badge at the top. Ensure all pricing information remains dynamic and accurate—don't hardcode any prices." **CRO Hypothesis:** The decoy effect and anchoring work together: highlighting a preferred plan makes it the "anchor" that other plans are compared against. Visual prominence (size, color, badges) draws attention to the recommended option. **Considerations:** - **Critical: Never hardcode prices**—they must remain dynamic - Don't invent "Most Popular" badges if there's no evidence this plan is actually preferred - Ensure the pricing table remains functional and all CTAs work - Test that the visual changes don't break the table layout on mobile ## 8. Mobile-Specific Optimizations **Prompt:** > "On mobile only, make the main CTA button full-width and increase its size. Move it to a sticky position at the bottom of the screen after the user scrolls past the hero section. Ensure the button text is large enough to read easily and maintains good contrast." **CRO Hypothesis:** Mobile users have limited screen space and shorter attention spans. Sticky CTAs ensure the primary action is always accessible, reducing friction. Full-width buttons are easier to tap on mobile devices. **Considerations:** - Specify "on mobile only" clearly in the prompt - Test that the sticky behavior doesn't interfere with page content - Ensure the button doesn't cover important content when sticky - Verify touch target size meets accessibility guidelines (minimum 44x44px) ## Common Improve Flow Prompts For prompts to fix common styling and layout issues when iterating on existing variants, see [Common Improve Flow Prompts](/editor/prompting-improve). This guide covers alignment issues, margin and spacing problems, container constraints, flex flow issues, grid column spanning, z-index layering, and sticky positioning. ::: tip Building on Examples These examples are starting points. Combine techniques (e.g., add trust badges + optimize CTA copy) for more comprehensive experiments. Always test one change at a time initially, then iterate based on results. ::: --- # Source: https://docs.getdalton.com/editor/prompting-improve # Common Improve Flow Prompts These prompts are examples you can use for solving common issues with experiments. ::: tip Using Add Context **Crucial Step:** Before using these prompts, it might be useful to click the **"Add Context"** button in the editor and select possible relevant elements. This gives Dalton the context it needs to apply these fixes correctly. ::: ## 1. Center multiple items vertically Use this when multiple items, like text, badges or icons don't line up properly on the same line. **Copy-paste prompt:** > "Apply `display: flex` and `align-items: center` to the container to vertically center the children on the same baseline." ## 2. Center buttons horizontally Use this when buttons are not centered in their container. **Copy-paste prompt:** > "Set `justify-content: center` on the parent flex container to align these buttons horizontally in the middle." ## 3. Stack elements on mobile Use this when elements look good side-by-side on desktop but need to stack on mobile. **Copy-paste prompt:** > "On mobile, use `flex-direction: column` and `align-items: center` to stack and center these elements. On desktop, keep them in a row." ## 4. Add breathing room inside a container Use this when content is touching the edges of its container. **Copy-paste prompt:** > "Add padding to the container so the content doesn't touch the edges. Use standard spacing values found elsewhere on the site." ## 5. Add space between items Use this when items in a list or row are too close together. **Copy-paste prompt:** > "Increase the `gap` property of the flex/grid container to add more space between these items. Match the spacing used in similar sections." ## 6. Add space below an element Use this when an element is too close to the section below it. **Copy-paste prompt:** > "Add `margin-bottom` to this element to separate it from the section below. Use a standard spacing value from the site's design system." ## 7. Make an element full width Use this when an element should span the entire width of its container but doesn't. **Copy-paste prompt:** > "Force this element to span the full width. If it's in a grid, use `grid-column: 1 / -1`. If it's in a flex container, set `width: 100%`." ## 8. Make a banner edge-to-edge Use this when a banner needs to break out of its parent container to touch the screen edges. **Copy-paste prompt:** > "Make this banner edge-to-edge. Use the `:has()` selector to target the parent container and make it full width." ## 9. Constrain width to match page Use this when an element is too wide and needs to match the standard page width. **Copy-paste prompt:** > "Constrain this section to the standard page width. Match the site's container width and use `margin: 0 auto` to center it." ## 10. Stack grid items on mobile Use this when a grid layout needs to become a single column on mobile. **Copy-paste prompt:** > "Change the grid layout on mobile: set `grid-template-columns: 1fr` so each card takes up the full width of the row." ## 11. Bring an element to the front Use this when an element (like a popup or badge) is hidden behind other content. **Copy-paste prompt:** > "Set `position: relative` (or absolute) and increase the `z-index` to ensure this element appears on top of other content." ## 12. Make a button sticky at the bottom Use this when you want a CTA to stay visible at the bottom of the screen while scrolling. **Copy-paste prompt:** > "Apply `position: sticky` and `bottom: 0` to make this button stick to the bottom of the viewport. Add a `z-index` to keep it above other content." ## 13. Make text readable on dark backgrounds Use this when text is hard to read against a background. **Copy-paste prompt:** > "Change the `color` to white (or a light shade) and add a subtle `text-shadow` to increase contrast against the background." ## 14. Make buttons easier to tap on mobile Use this when buttons are too small for touch screens. **Copy-paste prompt:** > "Set `min-height: 44px` and `min-width: 44px` on the button to meet accessibility touch target standards." ## 15. Prevent text from overflowing Use this when long text is getting cut off or spilling out of its container. **Copy-paste prompt:** > "Set `overflow-wrap: break-word` and `word-break: break-word` to prevent long text from overflowing the container." --- ::: tip Using Add Context for Container Issues The "Add Context" button is a UI tool in the editor that lets you click on elements on the page to provide additional context. When fixing container or layout issues, click "Add Context" and select the parent container element or a similar element that has the correct styling. This helps the AI understand the layout structure and apply the correct fix. Look for common container class names in the HTML when selecting elements. ::: --- # Source: https://docs.getdalton.com/editor/prompting-terms # Common Web Design Terms Understanding basic web design terminology helps you write clearer prompts. Here are the most common terms you'll encounter: ## HTML, CSS & JavaScript A web page is made up of three parts: - **HTML**: What is it? Also called the markup. - **CSS**: What does it look like? Commonly referred to as styling. - **JavaScript**: What does it do? This is the logic or interactivity part of the website. ## Axes - **x axis**: This refers to the horizontal or left-right direction of a web page. - **y axis**: This refers to the vertical or up-down direction of a web page. - **z index**: This refers to the 'depth', and decides, if two elements are overlapping, which one will be shown on top. **Examples in prompts:** - "Add some margin on the x axis, so the text doesn't stick to the sides." - "The icon and text are not centered on the y axis." - "Make sure the popup has a higher z-index than the rest of the page." **Positioning** - **Sticky**: This term is often used to describe something that is fixed in place when scrolling, useful for things that always need to be visible, like navigation menus or popups. **Examples in prompts:** - "Add a sticky buy button on mobile" - "Make sure the popup is sticky, so it's always visible on the page." **Examples in prompts:** - "Make the CTA button sticky at the bottom of the page on mobile" - "Layer the badge above the image using a higher z-index" - "Absolutely position the icon in the top-right corner of the card" ## Spacing To describe spacing inside and around an element, we use different terms. - **Margin**: Space *outside* an element, between it and other elements. Use when you want to move an element away from others. - **Padding**: Space *inside* an element, between its border and content. Use when you want to add space inside a button, card, or container. - **Gap**: For elements aligned in a grid, the spacing between grid items is often referred to as gutters, or gaps. **Examples in prompts:** - "Add more padding inside the button" (makes the button bigger internally) - "Add margin above this section" (creates space between this section and the one above) - "Increase the padding on mobile only" (makes content less cramped on small screens) ## Alignment - **Horizontal alignment**: Left, center, or right. Use terms like "center this text" or "align the button to the right" - **Vertical alignment**: Top, middle, or bottom. Use terms like "vertically center the content" or "align items to the bottom" **Examples in prompts:** - "Center the headline horizontally" - "Vertically center the button in the hero section" - "Align the trust badges to the right on desktop" ## Other Common Terms - **Responsive**: Adapts to different screen sizes (mobile, tablet, desktop) - **Above the fold**: Content visible without scrolling (most important area) - **CTA (Call-to-Action)**: Buttons or links that prompt users to take action - **Hero section**: The main banner area at the top of a page, usually containing the headline and primary CTA --- # Source: https://docs.getdalton.com/experiments/how-experiments-run # How Experiments Run Every Dalton experiment is a straight A/B test. Traffic splits evenly between your original page and each variant, the split never moves, and the result is read at the end of a window fixed before launch. ![A running experiment counting down to its conclusion](/v2/experiment-running.png) ## The planned window Dalton sets a conclusion date before the test starts, based on the traffic the targeted pages get. | Window | Given when | | --- | --- | | **2 weeks** | The pages can send about 5,000 visitors to each variant in that time | | **4 weeks** | They need longer | | **6 weeks** | They cannot reach it. Also the hard ceiling | Windows are always whole weeks, so a run counts the same number of Mondays as Saturdays. For the first three days the plan shows as two weeks and is provisional, until there is enough traffic to project from. Days only count while the test is collecting. Pausing does not advance the countdown. ::: tip Check the window before you launch The targeting picker estimates **time to results** before you commit. Widening the targeting is cheaper than waiting. See [Targeting Groups](/experiments/targeting). ::: ## Why no leader appears early While a test runs, **Leading variant** stays empty even when the numbers look convincing. Lift and chance to beat are shown throughout, but no leader is named until the window completes. Stop a test the moment it looks good and you will stop it on the days it happened to look good. Two exceptions, both using a calculation that stays valid however often it is checked: - **A clear loser** is flagged for early stopping once every variant has 50 conversions and all are decisively behind. - **A clear win** can be called early, but only after it has held for two days. ## What Dalton needs before it reports Figures show as a dash until **every** variant, including the original, clears both bars: - **350 visitors** - **50 conversions** Conversions are the binding one. A page converting at 0.5% clears 350 visitors on two orders, and one more order then swings the lift by tens of percent. ## Calling the result | Chance to beat | Verdict | | --- | --- | | **95%+** | **Winner.** Deploy it, or conclude it | | **80-95%** | **Promising.** Worth another week if under the six-week ceiling | | **5-80%** | **No effect** | | **Under 5%** | **The original won** | A test that runs its full window without clearing the data bars is reported as inconclusive. The page is too quiet for that question, and running it longer will not fix it. ## While it runs - Do not stop a test on a bad day three unless Dalton flagged it. - Do not edit the original page mid-test. - Pause if something is broken. Changes revert instantly. Next: [Reading Your Results](/experiments/reading-results). --- # Source: https://docs.getdalton.com/experiments/overview # The Experiments Page Every test lives here, grouped by the pages it targets. ![The Experiments page](/v2/experiments-list.png) Each group is one [targeting group](/experiments/targeting). Drafts sit alongside live tests. | What you see | What it means | | --- | --- | | **Draft** | Built, never launched | | **Visitors and days left** | Running, counting down to its window | | **Promising** | Ahead, but not past the 95% bar | | **Winner +13.1%** | Finished and won, with the measured lift | | **Action required** | Finished, waiting on you to deploy or conclude | **Action required** is the one to act on. Until you deploy or conclude, the variant is no longer served and the finding is not recorded. The filter at the top narrows to these. Search by name, or filter by market, tag or status. Concluded experiments are hidden by default. ## Starting a test **New experiment** asks which pages to run on first, since targeting decides how long the test needs. **+ Experiment** on a group header skips that and uses that group. Both continue into the editor. --- # Source: https://docs.getdalton.com/experiments/reading-results # Reading Your Results ![A finished experiment with a winning variant](/v2/experiment-winner.png) ## The verdict banner When a test concludes, the banner gives you two actions: - **Deploy to 100%** sends all traffic to the winning variant and stops the test. - **Conclude & add to learnings** closes it and files what it found in [Learnings](/learnings). Conclude losing tests too. A failed variant still tells you something, but only if it is recorded. ## The summary cards **Leading variant** names the best variant, or tells you how many days are left. No leader is named before the window completes. **Conversion lift** is how much better the leader converted, with the range the true effect sits in. A range entirely above zero is what makes a win real. A range crossing zero means the direction is still unknown. **Chance to beat** is the probability the leader genuinely beats the original. 95% calls a winner. ::: tip Read the range, not the number "+13.1%" is a best guess. "+5.4% to +21.3%" is what the data supports. Forecast against the low end. ::: ## The table | Column | Meaning | | --- | --- | | **Split** | Share of traffic. Even, and fixed for the life of the test | | **Visitors** | Unique visitors who saw this variant | | **Add to cart** | Share who added to cart, when that goal is on | | **Conversion rate** | Share who completed your primary conversion | | **Revenue** | Total revenue from this variant | | **Revenue / visitor** | Revenue divided by visitors, with its range | | **Uplift** | Conversion rate against the original, with its range | | **Chance to beat** | Probability this variant beats the original | **Revenue per visitor is the one to watch.** It is conversion rate multiplied by average order value, so it catches a variant that converts more people onto cheaper products. Conversion rate up and revenue per visitor flat means the change moved who buys, not how much they spend. Revenue columns need the [Dalton Pixel](/advanced/pixels). ## Breaking it down **By device** and **By channel** re-run the comparison on a slice of traffic. A change can win on desktop and lose on mobile. Segments need 500 visitors per variant, so they appear later than the headline figures. **Simple**, **Detailed** and **Intervals** control how much of the table shows. Detailed adds orders and average order value. Intervals shows the range for every figure. ## Differences from GA4 Dalton and GA4 attribute sessions differently and exclude bots differently, and GA4 samples large reports. Act on the relative comparison. See [Analytics Integration](/technical/analytics-integration). --- # Source: https://docs.getdalton.com/experiments/targeting # Targeting Groups A targeting group is a set of URL rules describing a slice of your site: your home page, every product page, every collection except clearance. Groups are reusable, and the Experiments screen groups your tests by them. ![Choosing a targeting group](/v2/targeting-groups.png) Starting a new experiment opens this picker. Each group shows its traffic over the last 7 days and how many experiments use it. ## Building a group ![The targeting rule builder](/v2/targeting-builder.png) **Generate with AI** describes the pages in plain language and lets Dalton write the rules. It needs the Dalton script installed, since it reads your actual site. **Write myself** gives you the builder directly. ### Rules Each condition reads as: path **does** or **does not** *[operator]* *[value]*. | Operator | Matches when the path | | --- | --- | | **Exact match** | is exactly the value | | **Simple match** | equals the value, ignoring query parameters | | **Starts with** | begins with the value, such as `/products` | | **Ends with** | ends with the value | | **Contains** | contains the value anywhere | | **Wildcard** | fits a pattern, such as `/products/*` | | **Regex** | matches a regular expression | Combine with **AND** or **OR**, and nest groups for anything more involved. Rules match the **path only**. Query strings and `#` fragments are stripped first, so `/products/serum?utm_source=meta` is tested as `/products/serum`. ### The reach panel As you build, the panel underneath shows: - **Estimated reach**, visits in the last 7 days - **Pages matched**, distinct paths covered - **Time to results**, how long a test on this group would run Time to results uses the same calculation as an experiment's [planned window](/experiments/how-experiments-run#the-planned-window), so you can see before launching whether a group resolves in two weeks or six. Use the search box to type a real URL and confirm it matches. ## Choosing the scope A rule matching 40 product pages resolves in a fortnight where one matching a single page may never resolve. Widen for generic changes such as trust badges or delivery messaging. Narrow when the change only makes sense on one template. One constraint: **only test elements that exist, and mean the same thing, on every page in the group.** See [Multi-Page Experiments](/advanced/multi-page-experiments). --- # Source: https://docs.getdalton.com/faq # Frequently Asked Questions Quick answers to the most common questions. For detailed help, see our topic-specific FAQ pages below. ## FAQ by Topic - [Setup & Installation FAQ](/faq/setup) — Script installation, platforms, performance - [Editor & Experiments FAQ](/faq/editor) — Creating experiments, prompting, previews - [Integrations FAQ](/faq/integrations) — GA4, other tools, compliance For how tests are run and read, see [Experiments](/experiments/overview). --- ## Top Questions ### Will it slow down my site? No. Dalton loads in <50ms with zero performance impact on Core Web Vitals. ### What can I test? Text, copy, CTAs, section order, and layout. ### How long until I see results? Each experiment is given a planned window based on the traffic its targeted pages get, and the results screen counts down to it. See [How Experiments Run](/experiments/how-experiments-run). ### Does it work with my platform? Yes. Shopify, Webflow, WordPress, React, Next.js, headless—anything that outputs HTML. --- # Source: https://docs.getdalton.com/faq/editor # Editor & Experiments FAQ Quick answers about what you can test, how AI variants are generated, previews, and managing experiments in the editor. ## What can I test? Text, headlines, CTAs, button colors, form labels, section order, spacing, and new elements like trust badges. **Can't test:** Images, videos, navigation menus, or dynamic elements (prices, inventory). ## Why isn't my prompt working? Common causes: - Element is dynamic (price, size selector) - Prompt is too vague ("make it better" vs "make this one sentence") - Element is inside an iframe or web component See [Troubleshooting](/faq/troubleshooting) for solutions. ## How do I preview experiments? Use the preview link in the editor. For best results, right-click and open in incognito. ## Why does preview look different from live? Preview has slight overhead for debugging. Live visitors see instant changes (<50ms). If very different, try incognito mode. ## Can I undo changes? Yes. Use the undo button to revert changes. You can also delete a variant and create a new one if you want to start fresh. ## Does Dalton understand my brand? Yes. The AI learns from your page. Add custom guidelines in [Brand Context](/editor/brand-intelligence) for more control. --- # Source: https://docs.getdalton.com/faq/integrations # Integrations FAQ Quick answers about using Dalton alongside Google Analytics, other testing tools, heatmaps, and compliance frameworks. ## Does it work with Google Analytics? Yes. Dalton sends a `dalton_experiment` event to GA4 with the variant each visitor saw, so you can check experiment results in your own GA4 reports. See [Analytics Integration](/technical/analytics-integration). Contact us for other analytics tools. ## Can I use Dalton with VWO or Optimizely? Not on the same pages—multiple testing tools cause conflicts. We can help migrate your experiments. ## Can I run Dalton alongside my own A/B tests? Not recommended on the same pages. Choose one testing method per page for accurate attribution. ## Does Dalton work with Hotjar/heatmaps? Yes. Session recording and heatmap tools work fine alongside Dalton. ## Is Dalton GDPR/CCPA compliant? Yes. We only collect anonymized behavioral data—no personal information. We respect your existing cookie consent setup. --- # Source: https://docs.getdalton.com/faq/setup # Setup & Installation FAQ Quick answers about installing the Dalton script, performance impact, supported platforms, and cookie consent. ## Will it slow down my site? No. Dalton loads in <50ms with zero performance impact on Core Web Vitals. No flickering, no layout shifts. ## Will Dalton affect my SEO? No. Dalton makes client-side changes only—search engines see your original page. ## Should I use Google Tag Manager? We recommend installing directly in your HTML `` rather than GTM. Direct installation is faster and more reliable. ## Does it work with cookie consent (OneTrust)? Yes. Dalton detects consent automatically and supports almost every banner out of the box, including OneTrust (`C0002`) and Google Consent Mode. Visitors see experiment variants regardless of consent — the anonymous experiment data lives in browser storage — and Dalton only writes its cookies once analytics consent is granted. See [Cookies & Storage](/technical/cookies-and-storage) for the full list of cookies, the domains to allow in your CSP, and how to declare Dalton in your banner. ## Which platforms are supported? Any platform that outputs HTML: Shopify, Webflow, WordPress, Framer, React, Next.js, Vue, Angular, headless setups, and custom builds. ## Does it work with headless/SPAs? Yes. Dalton works at the HTML layer—no backend integration required. ## Which languages are supported? All languages. For multi-language sites, each language needs separate setup. --- # Source: https://docs.getdalton.com/faq/troubleshooting # Troubleshooting Common issues and how to resolve them. ## Quick Reference | Symptom | Quick Fix | Section | |---------|-----------|---------| | Script not detected | Check it's in ``, clear cache | [Installation](#installation-issues) | | Experiments not showing | Try incognito, check if set to Live | [Installation](#installation-issues) | | "Can't find location" error | Select a parent element, check for iframes | [Editor](#editor-issues) | | Prompt not working | Be more specific, avoid dynamic elements | [Editor](#editor-issues) | | Mobile looks wrong | Preview mobile before launch, use "on mobile only" | [Editor](#editor-issues) | | No data in dashboard | Verify script, check experiment is Live, wait 24-48h | [Results](#results-dashboard-issues) | | Results don't match GA4 | This is normal—relative comparison is still accurate | [Results](#results-dashboard-issues) | | Significance taking too long | Reduce variants, focus on high-traffic pages | [Results](#results-dashboard-issues) | | Preview looks slow/different | Use incognito, live is faster than preview | [Preview](#preview-issues) | ## Jump To - [Installation Issues](#installation-issues) - [Editor Issues](#editor-issues) - [Results & Dashboard Issues](#results-dashboard-issues) - [Preview Issues](#preview-issues) --- ## Installation Issues ### Script not detected **Symptoms:** Dashboard shows "Installation required" even after adding the script. **Check:** - Script is in the `` section, not `` - Script is placed high in the `` (before other scripts) - No typos in the script snippet - Page has been refreshed/cache cleared **Solution:** Use browser DevTools (F12) → Network tab → search for "dalton" to verify the script is loading. --- ### Experiments not showing **Symptoms:** Script is installed but experiments don't appear on the page. **Check:** - Experiment is set to "Live" not "Paused" - You're viewing the correct URL - Cookie consent has been accepted (if required) - You're not in a cached version of the page **Solution:** Open an incognito window and visit the page. If experiments appear there, it's a caching issue. --- ## Editor Issues ### "Can't find location to place experiment" **Symptoms:** Error appears when trying to create an experiment. **Common causes:** - Element is inside an iframe - Element loads dynamically via JavaScript - Element is inside a shadow DOM component **Solution:** Try selecting a parent element, or verify the element exists in the static HTML. --- ### Prompt not working / errors **Symptoms:** AI returns an error or unexpected result. **Common causes:** - Element is dynamic (price, stock, selector) - Prompt is too vague - Element is complex (multi-nested components) **Solutions:** - Be more specific: "Make this one sentence" not "Make it shorter" - Avoid dynamic elements like prices or inventory - Try a simpler element first --- ### Mobile view looks wrong **Symptoms:** Experiment looks good on desktop but broken on mobile. **Cause:** AI optimizes for the current view. **Solution:** - Always check mobile preview before launching - Use "on mobile only" in prompts for mobile-specific changes - Create separate prompts for mobile adjustments --- ## Results & Dashboard Issues ### No data showing **Symptoms:** Dashboard shows zero sessions or conversions. **Check:** - Script is installed correctly - At least one experiment is live - Conversion goal is configured - Sufficient time has passed (24-48 hours minimum) --- ### Results seem inaccurate **Symptoms:** Numbers don't match Google Analytics. **Possible causes:** - Different attribution windows - Bot traffic affecting one tool differently - Sampling differences **Solution:** Dalton's relative comparison (variant vs baseline) remains accurate even if absolute numbers differ slightly from GA4. --- ### Significance taking too long **Symptoms:** Experiments running for weeks without reaching significance. **Common causes:** - Low traffic volume - Low conversion rate (under 2%) - Too many variants splitting traffic **Solutions:** - Reduce number of variants - Focus on higher-traffic pages - Consider using click-through rate instead of purchase for faster learning --- ## Preview Issues ### Preview looks different from live **Symptoms:** Preview link shows slow loading or different styling. **Cause:** Preview mode has additional debugging overhead. **Solution:** Right-click preview link → Open in incognito. Live visitors see instant changes (<50ms). --- ### Preview shows wrong variant **Symptoms:** You keep seeing the same variant in preview. **Cause:** Cookie persistence. **Solution:** Use incognito mode or clear cookies to see different variants. --- ## Still Need Help? If you can't resolve an issue: 1. Take a screenshot of the error 2. Note the page URL and browser 3. Contact support with these details We typically respond within 24 hours on business days. --- # Source: https://docs.getdalton.com/getting-started/before-you-go-live # Before You Go Live A 5-minute checklist to review targeting, goals, and variant quality before publishing your experiment to live traffic. ## Quick Checklist - Preview looks correct on **desktop** - Preview looks correct on **mobile** - AI-generated content is accurate - Multi-page experiments work on **all** pages - Conversion goal fires on a page where Dalton is installed ## Preview Both Devices Always check desktop AND mobile before launching. Changes that look great on one may break on the other. ## Review AI Content Read through generated content and check: - **Accuracy** - Claims and numbers are correct - **Brand fit** - Tone matches your voice - **Compliance** - No misleading promises ::: tip Add restrictions in [Brand Context](/editor/brand-intelligence) to prevent issues upfront. ::: ## Multi-Page Experiments If running a multi-page experiment, preview at least 3-5 different URLs that match your pattern before launching. See [Multi-Page Experiments](/advanced/multi-page-experiments) for important guidelines. ## Verify Conversion Goal Make sure your goal fires on a page where Dalton is installed. If using a "thank you" page goal, Dalton must be on that page too. ## If Something Goes Wrong 1. **Stop the experiment** - Changes revert instantly 2. **Fix the issue** 3. **Relaunch** There's no penalty for stopping. Better to pause and fix than let a broken experience run. --- # Source: https://docs.getdalton.com/getting-started/first-experiment # Your First Experiment Two ways in. The CRO Agent hands you a test that is already built. Or you pick the pages yourself. ## Before you start - **The Dalton script is installed.** Check **Connectors → Tracking**. See [Installation](/getting-started/installation). - **Your conversion is detected.** Check **Settings → Conversions**. A goal reading *not detected* means the test runs its full window with no result. See [Conversions & Goals](/settings/conversions). ## The short way: from the CRO Agent Open **[CRO Agent](/cro-agent)**. Each opportunity has a proposed test attached. **Open test** builds it and opens the editor with a variant already made, so there is no targeting to define and no first prompt to write. Skip to [step 3](#_3-check-it). Everything below is the manual route, for your own ideas. ## 1. Pick the pages **Experiments → New experiment.** Choose a [targeting group](/experiments/targeting) or create one. Watch **time to results**: if it says six weeks, widen the targeting now. ::: tip Start where the traffic is A home page or product template resolves in a fortnight. A quiet landing page may never resolve. For a first test, you want to see a result. ::: ## 2. Build the variant The editor opens with your variants along the top, a live preview in the middle, and the **Experiment agent** on the right. Take one of the suggested starting points, or describe the change yourself. Click any element in the preview to point the agent at it, which keeps your instruction short: with the headline selected, "make this specific about next-day delivery" is enough. Every change is listed in the left panel. See [Prompting Best Practices](/editor/prompting-best-practices). ## 3. Check it - **Toggle to mobile.** Most stores take most of their traffic there. - **Scan the QR code** to open the variant on your phone. - **Read the copy.** The agent writes in your brand voice but does not know your promises. Check any claim about delivery, returns or pricing. Full list: [Before You Go Live](/getting-started/before-you-go-live). ## 4. Launch **Start Experiment** puts it live. Traffic splits evenly and Dalton commits to a conclusion date. Then leave it alone. Come back when it shows **Action required**, [read the result](/experiments/reading-results), and deploy the winner or conclude the test. See [How Experiments Run](/experiments/how-experiments-run). --- # Source: https://docs.getdalton.com/getting-started/installation # Installation Installing the Dalton script is required to launch your experiments live and start measuring data. ## Installation Overview Dalton works on any platform—React, Shopify, Webflow, Framer, WordPress, and more. The installation is straightforward: add our JavaScript snippet to the `` section of your pages. You can choose to install Dalton: - **Sitewide**: Enable Dalton across your entire website to detect optimization opportunities everywhere - **Specific Pages**: Install only on the landing pages you want to optimize ## Installation Instructions ### 1. Get Your Snippet In Dalton, go to **Connectors → Tracking → Dalton Script** and click **View instructions**. The panel shows your unique snippet, with tabs for the common platforms. ### 2. Add to Your Website Copy the snippet and paste it in the `` section of your HTML, as high up as possible. ::: tip Share with Developer Don't have direct access to your website code? Use the **"Share with developer"** button in the installation settings. This generates a shareable link that doesn't require a login and contains all the information your developer needs to install Dalton. ::: ### 3. Verify Installation Once installed, return to the install panel and click **"Verify Installation"** to confirm the snippet is working correctly. The **Dalton Script** row on the Connectors page then shows as **Installed**, with the number of events received in the last 7 days. **Incoming events** on that same row lets you check live traffic at any time. --- # Source: https://docs.getdalton.com/glossary # Glossary Key terms used throughout Dalton and this documentation. ## A ### A/B Test A method of comparing two versions (A and B) of a page to see which performs better. Dalton splits traffic evenly between them for a planned window, then compares the results. ## B ### Baseline Your original page without any Dalton modifications. Every experiment runs its variants against the baseline on an even split, so the two are always measured over the same traffic. ### Brand Context Settings where you define your brand voice, restricted words, and compliance requirements. The AI uses these when generating suggestions. ## C ### Chance to Beat A percentage (0-100%) indicating how likely a variant is to be genuinely better than the baseline. Dalton calls a winner at 95%. See [Reading Your Results](/experiments/reading-results). ### Conversion When a visitor completes a desired action (purchase, signup, form submission, click). This is what Dalton optimizes for. ### Conversion Goal The specific action you want visitors to take. Set this in the experiment settings so Dalton knows what to optimize. ### Conversion Rate The percentage of visitors who complete your conversion goal. Calculated as: (conversions / visitors) x 100. ## E ### Experiment A test running on your page with one or more variants. Dalton automatically distributes traffic and measures results. ## H ## L ### Learning A conclusion Dalton draws across several concluded experiments, describing what does and does not work on your store. See [Learnings](/learnings). ## M ### Multi-Page Experiment An experiment that runs across multiple URLs simultaneously. Changes apply to all pages in the experiment. ## P ### Planned Window The number of days an experiment is scheduled to run, fixed before launch from the traffic its targeted pages get. Always whole weeks. See [How Experiments Run](/experiments/how-experiments-run). ### Prompt Instructions you give the AI to generate or modify content. Better prompts lead to better results. See [Prompting Best Practices](/editor/prompting-best-practices). ## S ### Statistical Significance The point at which results are unlikely to be due to random chance. Dalton shows this as a "chance to beat" percentage, and calls a winner at 95%. ## T ### Targeting Group A reusable set of URL rules describing which pages an experiment runs on. See [Targeting Groups](/experiments/targeting). ## V ### Variant A modified version of your page being tested against the baseline. Each experiment can have multiple variants. ### Visitor A unique person viewing your page. Dalton tracks visitors (not page views) to ensure accurate experiment data. --- # Source: https://docs.getdalton.com/
# Introduction to Dalton Run A/B experiments on your website without waiting for developers. An AI agent builds the variants. You approve what goes live. [Book Short Demo →](https://calendly.com/vincent-getdalton/30min)
NEW The New Dalton is here. Take a tour of the platform: Overview, CRO Agent, Analytics, Experiments, the Editor and Connectors. → ## Key Features

🤖 AI Experiment Builder

Dalton suggests high-impact experiments. Accept with one click or prompt your own. AI generates variants in your brand voice—you approve before launch.

⚡ Measured on Revenue

Every test runs as an even A/B split over a planned window, and reports conversion rate, revenue and revenue per visitor per variant with a confidence figure.

⏱️ 5-Minute Installation

One script tag, one time. After that, marketing launches experiments without touching developers again.

🎨 Brand Intelligence

Dalton scans your existing copy and learns your tone. Every variant sounds like you wrote it—no brand guidelines to upload.
## Popular Use Cases
🛒

E-Commerce Product Pages

📊

SaaS Trial Optimization

📄

B2B Landing Pages

🎯

Ad Campaign Landing Pages

## How Dalton is Different Traditional A/B testing means waiting for developers, writing your own copy, and running one test at a time. Most teams give up after a few experiments. Dalton lets marketing teams run experiments independently. An AI agent builds the variants, you approve what goes live, and results are measured on revenue rather than clicks alone. | Traditional A/B Testing | Dalton | |------------------------|--------| | Developer builds each variant | AI agent builds variants, you approve | | Weeks to launch one test | Launch a test in minutes | | You write all the copy | AI writes on-brand copy for you | | Limited platform support | Works on any site (Shopify, Webflow, custom) | No more waiting for dev sprints. No more staring at blank pages. ## Frequently Asked Questions ### Will this slow down my site? No. Dalton loads in <50ms with zero performance impact. ### Can I use this with Google Analytics? Yes. Dalton integrates directly with GA4. ### Do I need developer approval? Only for the 5-minute script installation. After that, marketing teams work independently. ### What if traffic is too low? Dalton sets each test's planned window from the traffic the targeted pages actually get, so lower-traffic pages run longer before a result can be called. You see the estimate before you launch. See [How Experiments Run](/experiments/how-experiments-run). ### How much does it cost? Pricing is based on traffic volume. [Get in touch](https://calendly.com/vincent-getdalton/30min) to discuss your needs. [See All FAQs →](/faq)

See it work on your site in 15 minutes

Book a Demo
--- # Source: https://docs.getdalton.com/learnings # Learnings Dalton reads your finished experiments and writes up the pattern. Each learning is a claim about your store, such as "passive trust strips do not move conversion here", with the tests behind it. Expand one to see them. **No effect** findings count. They stop the same idea being run again next quarter. ## When learnings appear Dalton needs **three experiments with readable results**. One counts when at least two variants collected traffic, and either every variant reached about 2,000 visitors or the experiment has finished. Drafts never count. ::: tip Conclude your finished tests The usual reason this page is empty is tests left in **Action required**. Use **Conclude & add to learnings** on the [results screen](/experiments/reading-results). On quieter pages it is what makes a test count at all. ::: Conclude losers too, or Dalton cannot tell you what fails on your store. --- # Source: https://docs.getdalton.com/new-dalton
# The New Dalton A guided tour of the Dalton platform: what each section does and when to use it.
## Overview ![The Dalton Overview page](/new-dalton/overview.png) The Overview is your home base. It answers three questions at a glance: how the account is performing, what Dalton is recommending next, and what is live right now. **Recently Launched** lists your most recent experiments with their measured uplift and the sessions behind it, so you can see how live tests are trending without leaving the page. Alongside it, **Your website, analysed** surfaces the pages Dalton has flagged as underperforming or standing out, linking through to the analytics. ## CRO Agent ![The CRO Agent, with an opportunity and its proposed test](/v2/cro-agent.png) The CRO Agent keeps watch on your store and reports back the opportunities it finds, grounded in your analytics rather than generic best practice. Trigger a **custom scan** whenever you want it to look at something specific. Opportunities come one at a time. Each carries an impact rating, an explanation of what is going wrong, a screenshot pinpointing it on your site, and a proposed test that is ready to build. **Open test** takes it into the editor, **Discard idea** clears it. Tests you keep collect in **Saved**. See [CRO Agent](/cro-agent) for the full picture. ## Analytics ![The Analytics page, showing the conversion funnel and page breakdown](/new-dalton/analytics.png) Analytics gives you the full conversion funnel for your brand, across whichever period you select. The breakdown underneath shows which parts of the site are responsible. Switch between **Pages**, **Page groups**, and **Markets**, and narrow to entry pages only when you want to judge landing performance in isolation. Dalton ranks your **top performing** and **worst performing** pages side by side, with sessions, conversion rate, and bounce rate for each. For the underperformers, you also get an estimate of the conversions being lost. A **Traffic** panel breaks incoming sessions down by channel or referrer, with the conversion rate each one delivers. ## Experiments ![The Experiments page, with experiments grouped by the pages they target](/new-dalton/experiments.png) The Experiments page lists every experiment in the account, grouped by the pages they target. Each group shows a thumbnail of the page and the experiments attached to it, with live status, uplift, sessions, and experiment type. Drafts sit alongside running tests, so nothing gets lost between idea and launch. Use the controls in the **top left** to narrow the list. Search by name, or filter by market, tag, or status.
New experiments start from the **top right**. Dalton first asks which pages the experiment should run on. Pick one of your existing [targeting groups](/experiments/targeting), or create a new one: describe the pages and let Dalton write the rules, or write them by hand. Either way the panel underneath estimates the traffic the group covers and how long a test on it would take, so you can judge the scope before committing. Once the pages are set, you continue into the editor to build the variants.
![Choosing which pages an experiment should run on](/new-dalton/new-experiment.png)
## The Editor ![The Dalton editor, with the variant view on the left, a live preview in the centre, and the Experiment agent on the right](/new-dalton/editor.png) The editor is where a variant gets built. It opens on the page you targeted, with your variants along the top. Switch between them, or add another with **+**. The **left panel** is the variant view. It carries the variant's name, and beneath it every change made to that variant is listed out, so you can see the full set of modifications at a glance rather than hunting for them on the page. A fresh variant starts empty, prompting you to describe your first change. The panel also holds a **Preview on live website** link and a QR code, so you can scan and open the variant on your phone to check it on a real device. The **centre** is a live preview of your site. Toggle between mobile and desktop, and use the selection tools to point the editor at a specific element on the page. The **right panel** is the Experiment agent, a prompting window for building and fine-tuning. It opens with a few suggested starting points drawn from your page. Keep prompting to refine what the agent produces until the variant is right. **Start Experiment** takes it live. ## Connectors ![The Connectors page, showing tracking, analytics, store and ad platform integrations](/new-dalton/connectors.png) Connectors is where you confirm Dalton is receiving data and connect the rest of your stack. **Tracking** comes first. The Dalton Script is required. It goes in your site's `` and powers both A/B testing and analytics tracking. You can check incoming events here to confirm it is live, or open the installation instructions if it is not. The Dalton Pixel is recommended on top of it: it tracks purchases and revenue, so experiments are measured on money rather than clicks alone. From there you can link your **analytics** and **ad platforms**, with each integration showing its current connection status. Connecting these feeds richer data into the CRO Agent and analytics. --- # Source: https://docs.getdalton.com/settings/conversions # Conversions & Goals Conversions tell Dalton what counts as success. They are set once for the account and every experiment is measured against them. ![Conversion settings](/v2/settings-conversions.png) ## General conversion - **Purchase** is the primary conversion. Conversion rate, uplift and revenue per visitor are all calculated from it. - **Add to cart** is reported alongside it. Turn it off if it does not apply. Both work out of the box with the [Dalton Pixel](/advanced/pixels) or Google Analytics connected. **Customise** points a goal at your own event name or a URL path instead: a `/thank-you` page view for lead generation, a `trial_started` event for subscriptions. A customised goal can carry its own name, which is what results will call it. ## "Not detected" Dalton has not received that event recently. Experiments will still run, but with nothing to optimise against they never resolve. **Incoming events** shows what Dalton is actually receiving. Usual causes: - The Dalton Pixel is not installed, so purchases never arrive. - The event fires under a different name than the goal expects. - The conversion happens somewhere the Dalton script is not installed, such as a hosted checkout. ::: warning Check this before launching An experiment against an undetected goal collects visitors, no conversions, and runs its full window without a result. ::: ## Secondary metrics Extra events or page views reported in experiment results without being optimised for: newsletter signups, size-guide opens, returns to collection. Useful for spotting a variant that lifts purchases while halving something else. ## Reporting currency Revenue is converted to this currency everywhere. Detected from your sales, so change it only if it is wrong. --- # Source: https://docs.getdalton.com/technical/analytics-integration # Analytics Integration Dalton sends an event to Google Analytics 4 each time a visitor sees an experiment, tagged with the variant they were shown. You can use it to check an experiment's results against your own GA4 data, such as revenue, purchases and conversion rate per variant. [Events](#events-sent-to-google-analytics) · [Setup in GA4](#setup-in-google-analytics) · [Confirm experiment data](#confirm-experiment-data-in-ga4) · [Google Tag Manager](#google-tag-manager) ## Events Sent to Google Analytics On every page visit where an experiment is active, Dalton sends this event: | Event | Parameter | Value | Purpose | | --- | --- | --- | --- | | `dalton_experiment` | `variantId` | The active variant's ID | Identifies which experiment variant the visitor is exposed to | **Where to find the variant IDs:** open the experiment in Dalton. The experiment detail screen shows the ID of each variant. Note the IDs of the variants you want to compare, because you'll need them to build the report below. ::: tip Always pushed to the data layer The event is pushed to `window.dataLayer` on every qualifying page visit, even if you haven't connected GA4 to Dalton. You can pick it up in GTM (or any other tool that reads the data layer) before you finish the GA4 integration. ::: ## Setup in Google Analytics ### Step 1: Verify Events Are Coming In Before you set anything up, confirm that GA4 is receiving Dalton's events. 1. In GA4, go to **Reports → Realtime → Overview** 2. Open a page on your site where a Dalton experiment is active 3. In the Realtime report, check the **Event count by Event name** card and confirm that a **`dalton_experiment`** event shows up and is counting If `dalton_experiment` appears, data is flowing and you can continue. If it doesn't show up within a minute or two, the events aren't reaching GA4 yet. If your GA4 runs through GTM, see the [Google Tag Manager](#google-tag-manager) section below. ### Step 2: Register `variantId` as a Custom Dimension Register the `variantId` parameter as a custom dimension so you can use it in segments, explorations and audiences. 1. Go to **Admin → Custom definitions → Custom dimensions** 2. Click **Create custom dimension** 3. Set: - **Dimension name**: `Dalton Variant ID` (the label you'll see in reports) - **Scope**: **Event** - **Event parameter**: `variantId` 4. Click **Save** ::: tip No backfill Custom dimensions only apply to data collected after they're created, and can take 24–48 hours to populate. Create this before (or as soon as) you launch the experiment. ::: ## Confirm Experiment Data in GA4 With `variantId` registered, you can build a report that compares the variants of an experiment side by side on your own GA4 metrics. ### Step 1: Create a segment per variant 1. In GA4, go to **Explore** and start a **Blank** exploration. Name it after the experiment. 2. Set the date range to the dates the experiment has been running. 3. Next to **Segments**, click **+** and choose **Session segment**. 4. Name it after the variant (for example `Variant A – `). 5. Add a condition: pick the **`dalton_experiment`** event, click **Add parameter**, choose **Dalton Variant ID**, and set it to **exactly matches** that variant's ID. 6. Click **Save and apply**. 7. Repeat for the other variant, so you end up with one segment per variant ID. ::: tip Purchases in a later session A session segment only counts purchases made in the same session the visitor saw the variant. If your customers often buy on a later visit, create **User segments** with the same condition instead. ::: ### Step 2: Build the comparison 1. Under **Dimensions**, click **+** and add **Device category**, then drag it into **Rows**. This splits the numbers by device, and a **Totals** row shows the overall figure for each variant. 2. Under **Metrics**, click **+** and add the metrics you want to compare, for example: - **Sessions** - **Ecommerce purchases** - **Purchase revenue** - **Session key event rate** (conversion rate) - **Average purchase revenue** 3. Drag the metrics into **Values**. 4. Drag both variant segments into **Segment comparisons**. The table now shows each variant side by side, with its sessions, purchases, revenue and conversion rate from your own GA4 data. ::: warning Expect the numbers to differ from Dalton GA4 and Dalton attribute sessions differently, filter bots differently, and are affected differently by consent settings and ad blockers. GA4 also samples large explorations. The absolute numbers won't match Dalton exactly. What matters is whether the two sources point in the same direction. For the uplift figure and its confidence interval, use the experiment's results screen in Dalton. See [Reading Results](/experiments/reading-results). ::: ## Google Tag Manager If your GA4 setup runs through Google Tag Manager, the `dalton_experiment` event and its `variantId` parameter won't reach GA4 unless you forward them with a tag in GTM. 📥 Download the GTM container template and import it into GTM to set everything up in one go. To import the template: 1. In GTM, go to **Admin → Import Container** 2. Select the downloaded file 3. Choose your workspace 4. Pick **Merge** (so it doesn't overwrite your existing setup) and confirm 5. Publish ::: warning Important: set your own GA4 Measurement ID The template ships with a placeholder ID, so you **must** replace it with your own before you publish. In GTM, click the created **`Dalton_Tag`** and set the **Google Analytics Measurement ID** field to your GA4 Measurement ID (the `G-XXXXXXXXXX`). Until you do, no events will reach your GA4 property. **Where to find your Measurement ID:** 1. Log in to your Google Analytics account 2. Click **Admin** (the gear icon) in the bottom-left corner 3. Under the **Property** column, click **Data collection and modification**, then select **Data streams** 4. Click the **Web** tab and select your website's data stream 5. Your Measurement ID is displayed in the top-right corner of the stream details window ::: If you'd rather build it by hand, you don't need to set up the variables and trigger first. Start from a new tag and create them inline as you go. ### Step 1: Get your GA4 Measurement ID Copy your GA4 Measurement ID (the `G-XXXXXXXXXX`). You'll paste it into the tag in the next step. **How to find your Measurement ID:** 1. Log in to your Google Analytics account 2. Click **Admin** (the gear icon) in the bottom-left corner 3. Under the **Property** column, click **Data collection and modification**, then select **Data streams** 4. Click the **Web** tab and select your website's data stream 5. Your Measurement ID is displayed in the top-right corner of the stream details window ### Step 2: Create the GA4 Event tag Go to **Tags → New**, click **Tag Configuration**, and choose **Google Analytics: GA4 Event**. Name the tag **`Dalton_Tag`** and set: - **Measurement ID**: paste the `G-XXXXXXXXXX` you copied in Step 1 - **Event Name**: click the variable picker (the icon to the right of the field), pick **Built-In Variables**, and enable/select **Event** so the field becomes `{{Event}}`. This forwards the original event name (`dalton_experiment`) unchanged. ![GA4 Event tag configuration in GTM](/analytics/gtm-tag-config.png) ### Step 3: Add the event parameters (creating the variables inline) Still in the tag, expand **Event Parameters** and click **Add Row** for each parameter. For each row, click the variable picker on the **Value** field, then **+ (New Variable)** → **Data Layer Variable** to create it on the spot: | Parameter Name | New variable | Data Layer Variable Name | | --- | --- | --- | | `variantId` | `Dalton - Variant ID` | `variantId` | | `type` | `Dalton - Type` | `type` | `variantId` is the one you need for experiment reporting. The `type` row is included in the container template, and you can leave it in. Each Data Layer Variable should look like this (here, `Dalton - Type` reading the `type` key): ![Data Layer Variable configuration in GTM](/analytics/gtm-datalayer-variable.png) ### Step 4: Add the firing trigger (created inline) Still in the same tag, click the **Triggering** box, click **+ (New)** in the top-right, then choose **Trigger Configuration → Custom Event** and set: - **Name**: `Dalton - All Events` - **Event name**: `dalton*` with **use matches RegEx** ticked. This fires on `dalton_experiment`. ![Custom Event trigger configuration in GTM](/analytics/gtm-trigger-config.png) Save the trigger, then **Save** the tag. Your finished tag should look like this: ![Completed Dalton_Tag overview in GTM](/analytics/gtm-tag-overview.png) ### Step 5: Preview and publish Before publishing, click **Preview** in GTM and load a page on your site where a Dalton experiment is active. In the Tag Assistant preview window, you should see **`Dalton_Tag`** fire on the `dalton_experiment` event with the `variantId` parameter populated. To check it's reaching GA4, go to **Reports → Realtime → Overview** in Google Analytics. You should see **`dalton_experiment`** events coming in. Once that looks right, click **Submit / Publish** to make the container live. ::: warning Custom events blocked in GTM? Some GTM setups restrict which custom events can be forwarded to GA4. If `dalton_experiment` isn't showing up in GA4, check that the `Dalton - All Events` trigger isn't blocked by an exception or a consent setting, and that it's set as the tag's firing trigger. ::: ### Step 6: Continue in Google Analytics Once the events are reaching GA4, register the custom dimension and build your report. 👉 **[Go to Step 2: Register `variantId` as a Custom Dimension](#step-2-register-variantid-as-a-custom-dimension)** --- # Source: https://docs.getdalton.com/technical/cookies-and-storage # Cookies & Storage Dalton uses a small set of **first-party** cookies and browser storage entries to keep visitors in the same experiment variation across page views and visits. Nothing is shared across domains and no personal data is ever stored. This page is the authoritative reference for what Dalton writes to the browser and the two things you may need to add to your site: 1. [Allow Dalton's domains in your Content Security Policy (CSP)](#1-allow-dalton-s-domains-csp-firewall) 2. [Declare Dalton's cookies in your cookie banner / consent tool](#2-declare-dalton-in-your-cookie-banner) ## Cookies vs. storage at a glance Dalton uses two storage mechanisms with different rules: | | What it is | When it's written | Cleared after | |---|---|---|---| | **Browser storage** (`localStorage` + `sessionStorage`) | Anonymous experiment cache | Always — needed to render the right variation without flicker | 24 hours | | **Cookies** | Anonymous session & device IDs | **Only after analytics/performance consent** | 24 hours | Because the experiment data lives in `localStorage`/`sessionStorage` (which contain no personal data), visitors always see a consistent experience during their session — even before they accept cookies. Cookies are only used to recognise the same session across cookie-aware contexts, and are written **only once analytics consent is granted**. ## Cookies set by Dalton All cookies are **first-party** (set on your own domain), `Secure`, and `SameSite=Lax`. They are written **only after analytics/performance consent** (see [Consent handling](#consent-handling)). | Cookie | Purpose | Data stored | Duration | |---|---|---|---| | `dalton_session_id_` | Keeps the visitor in the same experiment variation across page views | Random anonymous session ID + the experiment/variation IDs the visitor is enrolled in | 24 hours | | `dalton_device` | Recognises a returning visitor so variations stay consistent across visits | Random anonymous device ID (UUID) | 24 hours | ::: tip No personal data These cookies contain only randomly generated identifiers and experiment assignments. No names, emails, IP addresses, or cross-site identifiers are stored. ::: ## Browser storage set by Dalton These entries hold the anonymous experiment cache. They are written regardless of consent because they contain no personal data, and they are what lets Dalton apply the right variation instantly with no flicker. | Key | Location | Purpose | Duration | |---|---|---|---| | `dalton_session` | `localStorage` + `sessionStorage` | Cached experiment assignments and variation content for the current session | 24 hours | | `dalton_device` | `localStorage` + `sessionStorage` | Anonymous device ID for returning-visitor consistency | Until cleared | | `dalton_st_redirected_` | `sessionStorage` | Prevents a URL split test from redirecting the same visitor more than once per session | Session | Expired entries are removed automatically the next time Dalton runs. ## Consent handling Dalton detects consent automatically and supports almost every cookie banner out of the box. **Cookies are only written once analytics/performance consent is granted.** Browser storage (above) is always available so the experience stays consistent. Dalton recognises consent from, among others: - **OneTrust** — performance/analytics category (`C0002`) - **Google Consent Mode v2** — `analytics_storage: "granted"` on the `dataLayer` - **Trustpilot** cookie compliance events - Common consent cookies (e.g. `cookieconsent_status`, `ot_eu_consent`, `cookielawinfo-checkbox-analytics`) When OneTrust is present, Dalton respects **only** OneTrust's decision. ### If your banner isn't detected automatically If you use a custom or less common consent tool, set the consent flag yourself once the visitor accepts analytics cookies: ```js // Grant consent (allows Dalton to write its cookies) window.dalton = window.dalton || {}; window.dalton.consent = true; ``` Set it back to `false` to stop new cookies from being written. Dalton re-checks this flag continuously, so it takes effect immediately when your banner state changes. --- ## What to add to your pages The Dalton snippet itself is all most sites need — see [Installation](/getting-started/installation). The two items below only apply if you run a strict CSP/firewall or maintain a manual cookie declaration. ### 1. Allow Dalton's domains (CSP / firewall) If your site sends a `Content-Security-Policy` header (or sits behind a firewall/content filter), allow Dalton's two domains: | Domain | Used for | CSP directive | |---|---|---| | `https://cdn.getdalton.com` | Loading the Dalton script | `script-src` | | `https://global.dalton-cdn.com` | Session & tracking API calls | `connect-src` | Example policy additions: ```http Content-Security-Policy: script-src 'self' https://cdn.getdalton.com; connect-src 'self' https://global.dalton-cdn.com; ``` For the fastest load, also preconnect to both (Dalton's standard snippet already includes these): ```html ``` ::: warning If your CSP includes `require-trusted-types-for 'script'`, Dalton (like most experimentation tools) cannot apply DOM changes. Exclude that directive on pages where Dalton runs. ::: ### 2. Declare Dalton in your cookie banner If you maintain a manual cookie declaration, add Dalton's cookies under your **Analytics / Performance** category so they are governed by the visitor's analytics consent: | Cookie | Category | Type | Duration | |---|---|---|---| | `dalton_session_id_` | Analytics / Performance | First-party | 24 hours | | `dalton_device` | Analytics / Performance | First-party | 24 hours | - **OneTrust:** map both cookies to the **Performance Cookies (`C0002`)** group. No code changes are needed — Dalton reads the OneTrust decision automatically. - **Google Consent Mode:** no action needed; Dalton honours `analytics_storage` automatically. - **Custom tools:** declare the cookies as above and signal consent with `window.dalton.consent` as shown in [Consent handling](#consent-handling). Most scanners also detect the `localStorage`/`sessionStorage` entries listed under [Browser storage](#browser-storage-set-by-dalton); declare them in the same Analytics / Performance category if your tool tracks storage. ## Questions? For privacy or security questions, email **info@getdalton.com** or see our [Privacy & Security](/technical/privacy-security) overview and full [Privacy Policy](https://www.getdalton.com/privacy-policy). --- # Source: https://docs.getdalton.com/technical/performance # Performance & SEO Dalton is designed for speed and has zero impact on your search rankings. ## Performance ### No Flickering Dalton loads in under 50ms—users never see flickering or content shifts when experiments are applied. ### Minimal Impact on Load Times We measure performance on pages before and after Dalton integration. Our findings show minimal practical impact, achieved through: - **Edge Content Delivery** - Content optimized at the edge for fast global delivery - **Efficient Payloads** - Minimized data transfer with smart optimizations ### Core Web Vitals Zero impact on Core Web Vitals scores. No layout shifts, no performance degradation. ## SEO **Dalton does not affect SEO.** - Search engines see your original page content - No cloaking or deceptive practices - Changes happen client-side after the page loads - Your organic rankings remain unaffected Dalton optimizes for real visitors without impacting how search engines crawl and index your site. --- # Source: https://docs.getdalton.com/technical/privacy-security # Privacy & Security Dalton prioritizes data privacy and security in all A/B testing operations. ## Cookie Consent Dalton automatically detects consent and supports almost all cookie banners out-of-the-box. Cookies are only written once analytics/performance consent is granted. Anonymous experiment data is held in browser storage (`localStorage`/`sessionStorage`) so visitors get a seamless, consistent experience during their session — even before they accept cookies. This storage contains no personal data. ## Cookies Used Dalton sets two **first-party** cookies (`Secure`, `SameSite=Lax`), only after analytics consent: ### `dalton_session_id_` - **Purpose**: Anonymous session identifier for experiment consistency - **Data Stored**: Random session ID plus the experiment/variation IDs the visitor is enrolled in (no personal information) - **Expiration**: 24 hours - **Domain**: Your website domain ### `dalton_device` - **Purpose**: Anonymous device identifier for consistent experiences across visits - **Data Stored**: Random device ID (no personal information) - **Expiration**: 24 hours - **Domain**: Your website domain For the full list of cookies and browser storage, consent integration, and the domains to allow in your CSP, see [Cookies & Storage](/technical/cookies-and-storage). ## What We Collect - **Anonymous identifiers**: Random strings to maintain test consistency - **Experiment participation**: Which tests a user is enrolled in - **Variation assignment**: Which version of a test the user sees - **Conversion events**: Anonymous goal completions and interactions - **Click events**: Anonymous clicks on your web pages - **Scroll events**: Only tracked on pages with live experiments ## What We DON'T Collect - **Personal information**: No names, emails, IP addresses, or identifying data - **Cross-site tracking**: Cookies are limited to your domain only ## Data Storage All Dalton data is processed and stored exclusively within the European Union. The primary data zone is eu-central. **Stored data includes:** - Anonymous session IDs and device IDs - Experiment participation records - Conversion rates and goal completions - Experiment content and aggregate insights ## Questions? For privacy or security questions, email us at **info@getdalton.com** View our full [Privacy Policy](https://www.getdalton.com/privacy-policy)