Chatbot Campaigns

Chatbot campaigns deliver a site-scoped shopping assistant through the browser SDK. A campaign combines widget presentation, prompt behavior, knowledge, product tools, safety controls, targeting, and optional workflow handoff.

Create the campaign

1. Open Dashboard → Chatbot and create a campaign or choose a template.
2. Campaign setup: select the site, name the campaign, and choose a goal: Product Discovery, Upsell, Cart Rescue, FAQ and Support, Discount Rescue, Lead Capture, or Post-purchase Guidance.
3. Configure welcome copy, theme, launcher, response length and tone, and product recommendation layout. Choose a placement: Bottom Right, Bottom Left, Sidebar Left, Sidebar Right, or Modal, and optionally Open chatbot automatically.
4. When it appears: choose launch triggers.
5. Who sees it: set targeting.
6. Assistant actions / Team help: define the assistant’s role, allowed topics, and failure behavior; add knowledge; and configure tools, discounts, and handoff only where the action is genuinely available.
7. Save as Draft until the evaluation checklist passes.

Product cards can render as a stacked grid or a horizontal carousel. The runtime uses catalog availability metadata, treating stock as authoritative when present and quantity only as fallback.

Knowledge and prompts

Knowledge can come from the product catalog, public site pages, and uploaded documents. Ingestion is asynchronous. Wait for sources to reach a ready state before evaluating answers. Test retrieval with questions that should cite the source and with near-miss questions that should not invent an answer.

Platform AI defaults can set model, generation attempts, tool-turn limit, retrieval limit, and similarity threshold. Campaign guardrails and knowledge settings take precedence when configured.

Conversation state is persisted per chatbot session. The runtime refreshes the hidden prompt preamble each turn while retaining prior non-preamble history.

Targeting and launch triggers

Chatbots support the same saved audience, page, device, location, intent, and ALL/ANY targeting model as overlays. Geo context is resolved server-side and bound into a short-lived targeting token. The message and session endpoints verify the runtime token, origin, campaign/site scope, targeting token, and geo context.

Launch triggers are the overlay triggers (Immediate, Time on Page, Scroll Depth, Exit Intent, Inactivity, Page Count, Element Click) plus URL Match. Trigger matching can be ANY or ALL. An impossible ALL URL trigger set is rejected during campaign validation.

Structured responses

The runtime can return deterministic components:

• product recommendations derived from trusted product tool output;
• focused question forms authored through structured generation;
• discount offer states derived from actual discount tool results.

Tools and discounts

Read tools let the assistant look up products, recommendations, campaign context, store policies, the shopper's profile and orders (with consent), and cart state. Action tools include Create Coupon Code, Apply Discount Action, Create Support Escalation, Emit Workflow Event, Send Webhook Handoff, and Send Email Handoff.

In Discounts and coupons, offer codes come from two sources:

• Merchant offer codes that you enter manually, one per line as CODE | 15% or CODE | 10 USD;
• up to 20 imported store coupons, which are re-checked on every message.

Set a maximum percentage or amount and Require approval above thresholds to keep offers within policy. Turning on coupons or discounts requires at least one offer.

Create Coupon Code always hands out one of these existing codes; Upsurge never creates or changes discounts in your store. Apply Discount Action cannot apply a discount automatically on Shopify or WooCommerce sites; the tool reports that the connector is unsupported. On sites installed with a manual tag, it behaves like Create Coupon Code and hands out an existing code.

Question answers return through the normal message endpoint. Product and discount components are never accepted directly from model-authored component payloads.

Personalization and handoff

When the SDK provides an identified user or device ID, the runtime can read consented fields allowed for the chatbot surface. Hidden context may support greetings or relevant preferences, but is removed before transcript persistence. Public config never exposes profile values.

Handoff can go to a Workflow, a Webhook, or Email. A workflow handoff runs a published workflow through its campaign trigger. Validate the destination, payload, consent, and failure response on staging before activating the campaign.

Experiments

Compare complete chatbot campaigns against the current one with Experiments. Each variant is a full chatbot campaign; the control is the source campaign.

Release checklist

• Ask supported catalog and policy questions.
• Ask an out-of-scope question and verify the safety response.
• Test missing knowledge, unavailable products, tool failure, and long conversation history.
• Verify question forms, product layouts, discount states, and mobile behavior.
• Confirm geo/page/device targeting with a clean session.
• Verify handoff and discount events only fire for real outcomes.

Measure

Track opens, messages, prompt variants, rendered responses, tool calls/success/failure, handoff requests, goals, and issued discounts. Runtime observability also stores model, prompt ID/variant/version, retrieval count, outcome, and handoff status for governed analysis.

Troubleshooting

• Widget absent: inspect /chatbots/config, campaign status, targeting token, trigger, and lazy bundle request.
• Message rejected: verify the runtime token, origin, targeting token, session, and campaign/site scope.
• Weak answers: check source readiness, retrieval threshold, prompt scope, citations, and product availability.
• No handoff: confirm the handoff target is configured and, for workflows, that the workflow is published.