🎯 CTAs

Spec map

Home: All V2 Specs · Foundation: Data System (UVP) Mode(s): Relationship Mode Related specs: Data System (UVP), Forms, Surveys

🎯 Goals

Core Architectural Idea

Deliver a lightweight, conflict-free behavioral runtime that renders VRM-configured CTAs on customer sites. Five Formats
Offer a constrained set of formats and ratios that keep the builder fast and analytics comparable. Component System
Provide a drag-and-drop, auto-arranged component set for building CTA content without pixel-pushing. Politogy Visitor ID
Maintain a privacy-respecting first-party visitor identifier that merges into the UVP on conversion. Triggers and Targeting
Fire CTAs only when both behavioral trigger and contextual targeting conditions are satisfied, with anti-annoyance defaults. Stranger Conversion
Convert anonymous visitors in-place via constrained inline capture without leaving the page. Animations
Provide a constrained, accessible animation set that respects motion and contrast standards. Paginated Survey
Deploy existing Live Surveys as behaviorally-triggered, paginated, partial-capturing CTAs. A/B Testing
Run statistically honest two-variant CTA tests that only declare winners on sufficient data. Lifecycle
Manage CTA states with version-bucketed analytics and attribution-preserving edit constraints. Web Engagement Profile
Write rich pre-conversion behavioral profiles to the UVP under standard exposure controls. Permissions
Apply role-based access with live deployment gated to Admin and Manager.

Mode: Relationship Mode Status: Conceptual Spec — V1 Scope Definition Companion specs: vrm-forms (shared builder, field library), vrm-surveys (paginated survey embedding), vrm-data-system (UVP, identity matching, visitor ID merge), politogy-vrm-brand

1. What This Product Is

CTAs are behaviorally-triggered conversion widgets that the user builds in VRM and deploys across any website they control. Every CTA — a modal that pops up on scroll, a slide-in that appears after 30 seconds, a sticky banner on the homepage, an inline block in a blog post — is built in the same framed canvas as Forms and Surveys, then pushed live to the customer’s site without touching code.

The mechanic: the customer drops a single VRM header script tag into their site, once. From that moment forward, every CTA built in the VRM dashboard deploys live across their site (or selected pages) in real time. No engineer required for each new CTA. No redeploy. Configure in VRM, save, done.

Product thesis: Relationship Mode’s three big tools — Forms, Surveys, CTAs — work together as a stranger-to-supporter pipeline. Forms capture intent when a visitor is ready to give it. Surveys engage a known list. CTAs are how you reach the visitor who isn’t ready yet — the anonymous web traffic that came to your site, scrolled past your hero section, and would have left if you hadn’t intervened with the right offer at the right moment.

CTAs are the acquisition surface for strangers. Forms are the conversion form. Surveys are the engagement instrument. CTAs are what gets a stranger to the point of being one of those things.

2. Mode Architecture

CTAs live exclusively inside Relationship Mode, alongside Forms and Surveys. They share the builder infrastructure but introduce a fundamentally different deployment paradigm: CTAs run on websites the customer controls, not on Politogy-hosted pages.

Product	Where It Lives	Audience	Primary Job
Forms	Politogy-hosted URL or embed	Self-selected (clicked the link)	Capture an individual contact’s info
Surveys	Politogy-hosted URL or invite delivery	Targeted group OR public	Ask a group what they think
CTAs	Customer-owned websites	Anonymous traffic + known visitors, behaviorally selected	Intercept stranger traffic and convert it

The relationship: CTAs feed Forms feed Surveys feed Polls, all into the same UVP. A stranger sees a CTA. Clicks it. Lands on a Form (or a paginated Survey hosted inside the CTA itself). Becomes a contact. Three months later, gets invited to a Survey. Six months later, becomes part of a Poll sample.

3. The Defining Distinction — CTA vs. Form vs. Survey

These three live next to each other in the same Mode and are easy to confuse. Honor the distinction.

	CTA	Form	Survey
Where it appears	On the customer’s website, triggered by visitor behavior	At a Politogy URL or in an embed slot the user placed deliberately	At a Politogy URL, in an invite email, or in an embed slot
Who sees it	Anonymous web visitors + identified return visitors	Anyone who clicked the link or visited the embed page	Invited contacts or anyone with the public link
Trigger	Behavioral (scroll / time / intent / re-visit)	None — user navigated to it intentionally	Calendar (deployment window) or invite send
Default identity	Anonymous (visitor ID, not yet UVP)	Self-asserted on submission	Identified / Anonymous / Pseudonymous
Primary metric	Conversion rate (impression → action)	Submission count	Response count / aggregate insight
Composition	Static layout OR contains a Form/Survey	Linear field-by-field instrument	Linear instrument

The mental model: CTAs are the acquisition layer. Forms are the capture layer. Surveys are the engagement layer. A healthy Relationship Mode account uses all three.

4. The Core Architectural Idea — Two Things That Make CTAs Work

A CTA is two things at the same time:

A configuration the user designs in VRM — layout, content, animation, trigger, targeting
A behavioral runtime that executes on the customer’s website — the VRM JS script that decides which CTA to show this visitor at this moment

The VRM script (the “VRM Runtime”) is the load-bearing engineering piece. It is:

A lightweight (target <30 KB gzipped) JavaScript snippet
Installed once in the site header (or via GTM, or via WordPress/Webflow plugins)
Pulls CTA configuration from VRM’s CDN on page load, cached aggressively
Maintains a first-party visitor ID in the customer’s domain (the “Politogy Visitor ID” — see Section 7)
Evaluates trigger conditions client-side as the visitor interacts with the page
Renders the CTA at trigger time using vanilla JS + a scoped CSS namespace (no host page CSS conflicts)
Reports impressions, engagements, conversions, and dismissals back to VRM
Writes captured fields directly to the UVP via the standard submission pipeline

The architectural implication: CTAs are not a from-scratch product any more than Surveys were. The builder reuses Forms infrastructure. The submission pipeline is the same. The new components are: the framed canvas extended with layout-design primitives, the trigger/targeting/animation system, and — most importantly — the VRM Runtime. The Runtime is the work that doesn’t exist in Forms or Surveys today.

5. The Five CTA Formats

The format is the user’s first decision in the builder. It determines layout constraints, position rules, available animations, and recommended sizes. Five formats in V1.

Format	What It Is	Default Position	Typical Use
Modal	Center-screen overlay with backdrop	Center	High-intent capture; “before you leave” offers; signup pushes
Slide-in	Card that slides in from an edge, doesn’t cover content	Bottom-right (configurable to any corner)	Soft offers; secondary CTAs; persistent presence
Banner	Full-width bar across top or bottom	Top or bottom of viewport	Site-wide announcements; ongoing campaigns; petition pushes
Inline Block	Renders inside the page flow at a target selector	Wherever the user-supplied CSS selector resolves	Within-content CTAs; blog-embedded asks
Floating Button	Persistent small button anchored to a corner	Bottom-right (configurable)	Always-available “Join the fight” type entry; opens a larger CTA on click

5.1 Ratio / Size

Within each format, the user picks from a small set of standard ratios. This is intentionally constrained — endless sizing options make the builder slow and the output inconsistent.

Modal: Square (1:1), Portrait (3:4), Landscape (4:3), Wide (16:9), Compact (no ratio, content-sized)
Slide-in: Card (vertical), Wide Card, Compact
Banner: Thin (single line), Standard (two lines), Tall (call-to-action with image)
Inline Block: Auto-width, Constrained Max-Width
Floating Button: Small (icon only), Medium (icon + label), Large (label only)

Mobile sizing is responsive by default — every format degrades intelligently to mobile viewports. The user does NOT design separate mobile and desktop versions in V1 (that’s V2).

5.2 Why Formats Matter Architecturally

Each format has different animation defaults, different trigger compatibility (a Banner can’t really “exit-intent” the way a Modal can), different mobile behaviors, and different impression-counting rules. Formalizing them as a closed list with a defined small ratio set keeps the builder simple AND keeps the analytics comparable across CTAs.

6. The Component System

Inside the chosen format, the user drags components onto a canvas. V1 components:

Component	What It Does	Notes
Heading	Large display text	Inherits brand font; sizes via dropdown
Body Text	Paragraph text
Button	Clickable element with action (see Section 8)	The action engine
Image	Static image upload or URL	Auto-optimized for delivery
Video	YouTube / Vimeo / direct mp4	Defaults muted, autoplay-on-impression
Shape	Rectangle, circle, line — for visual structure	Brand-color preset palette
Inline Field	Email / Phone / Short Text capture field directly inside the CTA	The stranger-conversion centerpiece (see Section 9)
Spacer / Divider	Vertical/horizontal whitespace control
Countdown Timer	Counts down to a configured date/time	For urgency: “Election in 12 days”
Embedded Form	Reference to an existing Form	Inline rendering inside the CTA
Embedded Survey	Reference to an existing Survey (paginated)	See Section 11 — the paginated-survey-in-CTA pattern

V2: Image carousel, social proof counter (“234 people signed today”), confetti effect on conversion, animated number ticker, embedded calendar/scheduling component.

6.1 Layout

Components arrange in vertical stacks within zones (top zone, content zone, action zone). The user does not manipulate absolute coordinates in V1. They drop components into the canvas, the canvas auto-arranges them in a vertical flow, the user reorders by drag. This is the “no pixel-pushing” philosophy that keeps the builder fast.

V2 introduces side-by-side layouts (two columns) and absolute positioning for advanced users.

6.2 Styling

Per-component styling is minimal in V1:

Text: size, weight, color (from brand palette or custom hex), alignment
Button: background color, text color, corner radius (sharp / rounded / pill), size (sm/md/lg)
Image / Video: corner radius, aspect ratio crop
Shape: fill color, border color
Inline Field: label text, placeholder, required toggle, validation type

CTA-wide styling lives in the Style frame: background color (or image, or gradient), backdrop color (Modal format), padding, font family override.

7. The Politogy Visitor ID — The Stranger Identification Layer

This is the most important architectural decision in the spec. Without it, CTAs are a one-shot interruption engine. With it, they become a longitudinal acquisition channel.

7.1 What It Is

When a visitor lands on a page running the VRM Runtime, the Runtime sets a first-party cookie containing a Politogy Visitor ID — a unique anonymous identifier scoped to the customer’s domain. This ID persists across page views, across sessions, across days, as long as the cookie is intact. The visitor doesn’t know it exists; it’s invisible.

Every behavioral event during their visit (page views, scrolls, CTA impressions, CTA engagements, dismissals) is bound to that Visitor ID. The customer’s account in VRM accumulates a behavioral profile of every anonymous visitor.

7.2 The Conversion Merge

The moment the visitor converts — submits an inline field on a CTA, fills out a Form linked from a CTA, fills out a Survey, anything that gives Politogy an email/phone/name — the Visitor ID is merged into the resulting UVP. From that point on:

The visitor’s full behavioral history retroactively attaches to the UVP. The campaign suddenly knows: this person visited 4 times before converting, scrolled past the climate page each time, dismissed two CTAs before engaging with the third one.
Every future visit by that visitor is recognized as the known UVP. CTAs can now use UVP-aware targeting (“show this CTA only to known supporters” / “show this CTA only to first-time visitors”).
The UVP carries a web_engagement_profile substructure with the behavioral history.

This is what makes CTAs strategically valuable rather than just tactically. They aren’t impressions in a void — they’re the front edge of a longitudinal acquisition record.

7.3 Cross-Domain and Cross-Device

V1: single-domain Visitor IDs. A visitor’s ID on customer-site-A is separate from their ID on customer-site-B.

V2: Politogy-level Visitor ID linkage (if the same email shows up on two customer sites, the UVPs link via the standard cross-account behavior in vrm-data-system, but the anonymous IDs do not — that’s Politogy IP behavior, not customer-tier).

V1 cross-device: limited. If a visitor uses Phone and Laptop separately, they have two Visitor IDs until they convert on one of them. Then the converted UVP becomes the linkage point for future visits on both devices (because they’ll be matched to UVP after future identity matches). This is acceptable for V1.

The Visitor ID is a first-party cookie scoped to the customer’s domain. It does NOT carry across domains. It is NOT sold or syndicated. It IS subject to:

The customer’s cookie consent banner / GDPR / CCPA compliance (responsibility of the customer, but the Runtime supports gating)
Visitor’s right to clear (clearing cookies resets the ID; a new visit creates a new ID)
Politogy’s Aggregate Intelligence layer (anonymous behavioral signals feed into Politogy’s intelligence products, anonymized)

The platform Terms cover this generically. Customer-facing docs make it clear what’s tracked and why.

8. Triggers and Targeting — Two Different Things

This distinction is critical and often conflated in competitor tools. Get it right.

Trigger = “WHEN on this page do I fire?” — temporal/behavioral
Targeting = “SHOULD I fire at all for this visitor on this page?” — contextual/conditional

A CTA has exactly one Trigger and one or more Targeting Rules. Both must be satisfied for the CTA to fire.

8.1 V1 Triggers

Trigger	Configuration	Use Case
Immediate	Optional delay in seconds (0-30)	Welcome message, page-entry capture
Scroll Depth	Percentage (25 / 50 / 75 / 90)	Engaged-reader capture
Time on Page	Seconds (30 / 60 / 120 / custom)	Patient visitor capture
Exit Intent	Mouse-leave detected (desktop) / back-button gesture (mobile, best-effort)	Last-chance offer
Inactivity	Seconds without scroll/click (15 / 30 / 60)	Re-engagement
Click Trigger	Visitor clicks a specific element (selector or `[data-vrm-trigger]` attribute)	Manual user-invoked CTAs
Page View Count (this visit)	After N pages viewed	Engaged-session capture
Page View Count (lifetime)	After N visits across all sessions	Re-visitor capture

V1.5 additions: rage-click detection, deep-scroll-then-bounce-back, video-completion trigger, form-abandonment trigger.

8.2 V1 Targeting Rules

Targeting rules stack with AND. Multiple values within a rule stack with OR.

Rule	Configuration
Page URL	Match / contains / regex on path or full URL
Referrer	Match / contains on referrer URL (e.g., “from Facebook only”)
UTM Parameters	Match on utm_source / utm_medium / utm_campaign
Device Type	Desktop / Tablet / Mobile (any combination)
Visitor Type	First-time visitor / Returning visitor / Known UVP / Anonymous
UVP Segment	Specific segment / tag / list (only applies to identified visitors)
Geographic	Country / state / region (IP-based, best-effort)
Time of Day / Day of Week	Configurable window
Frequency Cap	Max N impressions per visitor per day / week / lifetime
Dismissal Memory	Don’t show again for N days after dismissal

8.3 Frequency Cap and Dismissal Memory Are Defaults

By default, V1 CTAs respect:

3 impressions per visitor per 24 hours maximum (cap)
Do not show for 7 days after dismissal (memory)

These are configurable but defaulted to prevent the worst CTA pattern: annoying users into bouncing. Aggressive defaults can be set per CTA when there’s good reason (e.g., a one-time legal disclosure).

9. Stranger Conversion — The Inline Capture Pattern

This is the centerpiece feature. CTAs can capture identity directly inside the widget without redirecting to a Form.

9.1 Inline Fields

The Inline Field component (Section 6) places a single Email, Phone, or Short Text capture field inside the CTA next to a Submit button. The visitor types, clicks, and is converted — all without leaving the page they were on.

Behavior:

Submission runs the standard VRM submission pipeline (identity match → UVP write).
Visitor ID is merged into the resulting UVP (Section 7.2).
A success state replaces the CTA content (“Thanks! We’ll be in touch.” or configurable).
The CTA respects a “submitted state” memory: this visitor doesn’t see this CTA again unless explicitly configured to re-show.

Inline Field types in V1:

Email (with email-format validation)
Phone (with country-code dropdown, E.164 normalization)
Short Text (for “What’s your name?” type quick captures)

A CTA may contain up to two Inline Fields in V1 (e.g., Email + First Name). More than that defeats the speed promise of inline capture — for richer capture, link to a Form.

9.2 One-Click Capture Variants

Some captures don’t require a field at all:

“Join” Button — Visitor clicks; if previously converted on this device, their UVP is recognized and a soft conversion is recorded (no field needed). If not previously converted, the button opens a follow-up state (inline field appears) or routes to a Form.
“Yes / No” Sentiment Capture — A two-button CTA captures a single-bit response and binds it to the Visitor ID. The visitor is still anonymous, but the campaign has a signal. (Promotes to UVP-attached on future conversion.)
“Share” Button — Native share with pre-filled message. Captures the share event but not a UVP.

9.3 QR-to-Convert (V1.5)

A CTA on a desktop site can display a QR code that, when scanned with a phone, routes the phone to a mobile-optimized capture page. The Visitor ID flows through the QR code as a parameter, so when the visitor converts on their phone, the conversion attaches back to the original desktop session. This is the bridge for offline-leaning audiences who don’t type on laptops.

9.4 SMS Opt-In (V1.5)

CTA displays: “Text JOIN to 503-555-1234.” Visitor texts; Politogy’s SMS gateway captures the phone, creates the UVP, and the CTA shows a success state on the desktop session (via Visitor ID linkage if the same browser made the request). Requires TCPA infrastructure.

10. Animations and Behavior

Animations are constrained to a closed set in V1 — enough creative range, no After Effects.

10.1 Entrance Animations

Animation	What It Does	Best Fit Format
Fade	Opacity 0 → 1 over 250ms	Modal, Inline Block
Slide-in Left / Right / Up / Down	Translates from off-screen to position over 300ms	Slide-in, Banner
Pop	Scale 0.85 → 1.0 with ease-out over 200ms	Modal, Floating Button
Drop-in	Translates down with bounce	Banner (from top)
No Animation	Appear instantly	Any (accessibility / low-distraction)

10.2 Exit Animations

Mirror the entrance animation by default (Slide-in-Left exits Slide-out-Left). User can override.

10.3 Idle Behavior

Some formats have ambient idle animations (V1.5):

Floating Button: subtle pulse every 8 seconds to draw the eye
Slide-in: gentle hover-lift on cursor proximity

V1: no idle animation. Static.

10.4 Accessibility

Respects prefers-reduced-motion — falls back to Fade or No Animation
All CTAs are keyboard-dismissible (ESC, Tab to dismiss button)
Inline Fields are screen-reader-labeled
Color contrast validated at save time

11. Paginated Survey in a CTA — The Composition Pattern

This is the feature Ben specifically called out. Architecturally, it falls out of the system if Surveys are properly first-class.

11.1 The Pattern

A CTA’s content can be either:

Static — heading, text, image, button, inline field, etc. (the default)
Embedded Survey — an existing Survey rendered inside the CTA container, paginated one question at a time

When the user chooses Embedded Survey, the CTA becomes a deployment vehicle for a Survey. The Survey’s questions render one per CTA “page” (the CTA stays mounted; the question changes). A progress indicator at the top shows “Question 2 of 5.” A Next button advances. On the last question, a Submit button completes the response.

11.2 What This Inherits From Surveys

The embedded Survey is the same Survey object defined in vrm-surveys. It inherits:

All field types (including Likert / NPS / Star Rating in V1.5)
The same submission pipeline → UVP write
The same lifecycle (only Live Surveys can be embedded; Closed Surveys can’t be embedded)
The same identity mode (Identified / Anonymous / Pseudonymous)
The same anti-abuse rules

The CTA acts as another deployment channel for the Survey, alongside Email, Public Link, QR, and Embed.

11.3 What’s CTA-Specific About It

The CTA wrapper provides:

The trigger (when does this Survey appear?) — a Survey deployed via CTA is a behaviorally-triggered Survey
The targeting (which visitors see it?) — Survey + visitor-segment targeting
The pagination UI (one question at a time, progress indicator)
The dismissal behavior (Survey can be exited mid-flight; partial responses captured)

11.4 Why This Is Smart

This composition unlocks behaviorally-triggered Surveys without building a parallel feature inside the Surveys product. A campaign can run a Survey that fires only after a visitor has read three pages on their site — that’s a higher-quality respondent than a random social-link click. It’s the platform-native version of every “in-app survey” pattern (Intercom, Hotjar, Typeform), available to political users.

11.5 Partial Response Capture

When a visitor starts an embedded Survey and exits mid-flight:

Responses to completed questions are captured as a partial response
The Visitor ID is linked to the partial response
If the visitor returns and the Survey is still Live, they resume where they left off (V1.5; V1 starts over)
Partial responses are reflected in Survey Results as “started but did not complete”

12. Deployment — The VRM Runtime

12.1 The Header Script

One header tag, installed once per site:

<script src="https://runtime.politogyvrm.com/v1.js" data-vrm-account="ACCOUNT_ID" async></script>

That tag is the entire installation. From it, every CTA built in VRM deploys live without further code work.

Installation paths:

Direct HTML edit — copy into <head>
Google Tag Manager — supported; account ID set via GTM variable
WordPress — official plugin (V1.5) for one-click install
Webflow / Squarespace / Wix — header injection slots; supported with brief setup guides
React / Vue / SPA frameworks — supported; the Runtime handles SPA route changes natively

12.2 Per-Page Embed Code (Alternate)

For users without site-wide header access, individual CTAs can be embedded as a one-off snippet:

<div data-vrm-cta="CTA_ID"></div>
<script src="https://runtime.politogyvrm.com/v1.js" data-vrm-account="ACCOUNT_ID" async></script>

This still uses the same Runtime, but anchors a specific CTA inline at the target element. Useful for inline blocks in CMSs that don’t allow header edits.

12.3 Installation Verification

When the user adds a site to VRM, the dashboard shows a “Connection Status” indicator that turns green when the Runtime is detected pinging from that domain. This is a critical onboarding cue — without it users will configure CTAs that never fire because the script wasn’t installed correctly.

12.4 What the Runtime Does on Each Page Load

Reads / sets the Politogy Visitor ID cookie
Fetches CTA configuration for this account (cached aggressively; refreshed in background)
Evaluates each CTA’s targeting rules against the current visitor/page
For each eligible CTA, sets up its trigger listener
Logs the page view as an impression event under the Visitor ID
On trigger fire: renders the CTA, logs the impression, attaches engagement listeners
On engagement / dismissal: logs the event
On conversion: submits via the standard submission pipeline, merges Visitor ID with the resulting UVP

13. The Three-Tab UI

Same three-tab pattern as Forms and Surveys.

13.1 Tab 1 — CTAs (Live, Scheduled, Draft, A/B Test)

Default landing tab. Sections:

Live CTAs — currently active. Row: name, format, trigger summary, sites/pages, impressions (7d), conversion rate, action menu.
Scheduled CTAs — configured to go live at a future time. Row: name, format, scheduled start, action menu.
A/B Tests — CTAs running as variants. Row: name, variant count, leader, statistical-significance indicator, action menu.
Draft CTAs — under construction. Row: name, last edited, completeness, action menu.

Clicking any row opens the CTA Detail View (Live/Scheduled → Analytics by default; Draft → Canvas).

13.2 Tab 2 — Canvas (Builder)

Identical framed canvas as Forms and Surveys, with CTA-specific frame composition:

Frame A — CTA Settings: Name, internal description, tags, A/B test toggle.

Frame B — Format & Size: The user’s first decision. Pick format (Modal / Slide-in / Banner / Inline Block / Floating Button) and ratio/size from the constrained set.

Frame C — Canvas: Drag-and-drop construction area. Components from the Component Library (Section 6) drop into vertical zones. The canvas previews the CTA at the selected format’s default position with the host page mocked behind.

Frame D — Component Library (left rail): Heading, Body Text, Button, Image, Video, Shape, Inline Field, Spacer, Countdown Timer, Embedded Form, Embedded Survey. Search at top.

Frame E — Style & Branding (right rail): Background, backdrop, padding, font family, color overrides. Account brand kit applied by default.

Frame F — Trigger & Targeting (right rail, replaces Forms’ “Publish & Distribute”): Trigger picker (one), Targeting Rules (stacked), frequency cap, dismissal memory.

Frame G — Animation (right rail, separate frame): Entrance animation + Exit animation pickers with preview.

Frame H — Deployment (right rail): Which sites this CTA runs on (account may have multiple registered domains), publish status toggle (Draft / Live), A/B configuration if applicable.

Frame I — Consent & Compliance: Inherited from Forms — required when Inline Field components or Embedded Forms/Surveys are present.

Live Preview Panel: A toggleable side panel that simulates the CTA on a representative page background, with controls to simulate trigger firing, dismissal, and conversion. Critical UX — without this users build blind.

13.3 Tab 3 — Analytics

The funnel view. Two layers:

Layer 1 — CTA-Level Funnel (default for any selected CTA):

Impressions (CTA rendered to a visitor)
Engagements (visitor interacted — clicked, scrolled within, started Inline Field)
Conversions (visitor completed the Inline Field, clicked through the Button to a Form, or submitted an Embedded Survey)
UVPs created vs. UVPs matched (of the conversions, how many were new vs. existing)
Conversion rate at each step

Visualized as a funnel chart with drop-off percentages. Time-series view available (daily / weekly / monthly).

Layer 2 — Cross-CTA Aggregate:

All CTAs across the account
Top-converting CTA
Top-converting trigger type
Top-converting format
Total UVPs created via CTAs in time window
Visitor-to-UVP funnel across the entire account

A/B Test Reporting:

Side-by-side variant performance
Conversion rate per variant with confidence interval
Statistical significance indicator (V1: ≥95% confidence highlights the winner)
One-click “Promote Winner” action

Per-Conversion Drill-down:

Click any conversion → see the resulting UVP
See the visitor’s full pre-conversion behavioral profile (which pages, when, dismissal history) — this is what the Visitor ID enables

14. A/B Testing

CTAs are the right place for V1 A/B testing because the variance is high and iteration is cheap.

14.1 V1 A/B Capabilities

Two variants per test (V1). V2 supports more.
50/50 split (V1). V2 supports custom splits.
Variants share the same trigger and targeting (the test is on content/layout/animation, not on when to fire)
Test runs until a minimum sample size is hit AND statistical significance is reached
One-click “Promote Winner” replaces the test with the winning variant, archives the loser

14.2 What’s Testable

Content (headline, body, button text), visual (colors, image, format), animation, inline field configuration (Email vs. Email+Name). NOT testable in V1: trigger, targeting, format-level (those are different CTAs).

14.3 Statistical Floor

V1 won’t declare a winner with <100 conversions per variant or <95% confidence. Below the floor, the UI says “Need more data” rather than misleading the user. This is the same epistemic honesty the Polling Engine enforces — and a quiet upsell signal for Polls when a campaign keeps running CTAs and finding “Need more data” as the answer to important questions.

15. UVP Provenance & Web Engagement Profile

Every CTA-driven conversion writes to the UVP with full provenance plus CTA-specific metadata:

CTA ID and version (which CTA, which version)
Trigger event (what fired the CTA when this visitor saw it)
Source URL (which page on the site)
Visitor session (full session before conversion, accessible via Visitor ID)
Pre-conversion behavioral profile: page views before conversion, time on site, prior CTA impressions and dismissals, referrer chain

This data writes to a new substructure on the UVP: web_engagement_profile. This substructure is:

Visible to the originating account (customer-tier)
Aggregated cross-account into Politogy’s Aggregate Intelligence layer (Politogy-tier)
Subject to the standard data exposure controls in vrm-data-system

The web_engagement_profile is rich Aggregate Intelligence feedstock. A visitor who consistently bounces from issue-policy pages but engages with candidate-bio pages is a different persuasion target than the reverse. Politogy’s AI can mine these patterns across accounts to refine propensity scoring (a Polling Engine input).

16. Lifecycle & State Machine

State	Behavior	Editable
Draft	Under construction; never fires	Fully
Scheduled	Configured but awaiting start time	Restricted (content lockable, deployment editable)
Live	Active on the customer’s sites	Restricted (see below)
Paused	Was Live, temporarily off	Fully
A/B Testing	Live as a test with variants	Restricted to test config changes
Archived	Retired; historical data retained	No

16.1 Editing a Live CTA

CTAs are more forgiving than Surveys (Survey instrument must be stable; CTA isn’t a measurement instrument):

Can change content, copy, image, color, animation at any time. Changes propagate via Runtime config refresh.
Can change trigger and targeting (but: prior impression data is bucketed by configuration version, see Section 17 versioning).
Cannot change Embedded Form/Survey reference once data has been captured against the original (would corrupt the conversion attribution chain).

16.2 Versioning

Every meaningful CTA edit creates a configuration version. Impression and conversion analytics are bucketed by version. The analytics view shows version markers on the time-series chart so the user can see “we changed the headline on Tuesday; conversion rate moved.” This is V1.

17. Permissions

Same role matrix as Forms and Surveys. Standard scope:

Role	Create CTA	Edit	View Analytics	A/B Test Authority
Account Admin	Yes	All	All	Yes
Account Manager	Yes	Own + assigned	In scope	Yes
Field User	No	No	Assigned only	No
Viewer	No	No	Read-only	No

Deploying a CTA to Live (the act of pushing live to the customer’s site) is gated to Admin + Manager only — this is a real-world action with real-world visibility.

18. V1 / V1.5 / V2 Scope

V1 — Ship

Five formats (Modal, Slide-in, Banner, Inline Block, Floating Button) with standard ratios
Eleven components (Heading, Body, Button, Image, Video, Shape, Inline Field, Spacer, Countdown, Embedded Form, Embedded Survey)
Eight triggers (Immediate, Scroll Depth, Time on Page, Exit Intent, Inactivity, Click, PV-this-visit, PV-lifetime)
Ten targeting rules (URL, Referrer, UTM, Device, Visitor Type, UVP Segment, Geographic, Time-of-Day, Frequency Cap, Dismissal Memory)
Entrance + Exit animations from constrained palette
Inline Field capture (Email / Phone / Short Text), up to 2 per CTA
One-click Capture variants (Join button, Yes/No sentiment, Share)
Politogy Visitor ID with first-party cookie + conversion merge to UVP
VRM Runtime header script with installation verification
Per-page embed code as alternate install
Paginated Embedded Survey composition
Paginated Embedded Form composition
A/B testing (2 variants, 50/50 split, significance-driven winner)
Three-tab UI with funnel analytics
Live Preview panel in builder
Pre-conversion behavioral profile on UVP
Frequency cap and dismissal memory defaults

V1.5 — Near-term Additions

QR-to-convert (mobile handoff)
SMS opt-in capture (requires TCPA)
Rage-click trigger, deep-scroll-bounce trigger, video-completion trigger, form-abandonment trigger
Idle animations (Floating Button pulse, Slide-in hover lift)
Resume partial Embedded Survey responses
WordPress official plugin
More A/B variants (3+) with custom splits

V2 — Defer

Mobile-specific design (separate mobile variant per CTA)
Side-by-side and absolute-positioning layout modes
Image carousel, social proof counter, confetti, animated number ticker, embedded scheduler
Cross-domain Visitor ID linkage
AI-suggested CTA optimization (“your conversion rate would lift 18% with a stronger headline — try these →”)
Multi-step CTA flows (CTA #1 → if dismissed → CTA #2 sequence)

V3+ — Aspirational

Personalized CTA content (visitor-segment-driven dynamic copy)
Predictive trigger optimization (AI picks the trigger based on per-visitor behavior)
Cross-account CTA performance benchmarking (Politogy Aggregate Intelligence product)
Voice / audio CTAs

19. Summary Mental Model

CTAs are the acquisition front door of Relationship Mode. They live on the customer’s website, get triggered by visitor behavior, and intercept stranger traffic before it leaves. Some convert via Inline Fields directly inside the CTA. Some convert via Embedded Forms and Surveys. All conversions retroactively attach the visitor’s full behavioral history to the resulting UVP via the Politogy Visitor ID.

The composition with Forms and Surveys is what makes this powerful: CTAs are deployment containers that can host the existing Forms and Surveys infrastructure. A “paginated survey in a CTA” is just a Survey deployed via a behaviorally-triggered container. The same Survey object, the same UVP write path, a new channel.

The Politogy Visitor ID is the load-bearing magic. Without it, CTAs are interruptions. With it, they’re the first frame of a longitudinal acquisition record that strengthens the UVP, feeds Aggregate Intelligence, and turns anonymous web traffic into the platform’s most valuable raw material.

North Star: A campaign should be able to install one script tag, build a CTA in three minutes, deploy it across their site instantly, watch strangers convert into UVPs in real time, and let the platform handle every visitor’s behavioral history for them. Everything in this spec serves that promise.

Developer Open Questions

These are the V1 architectural decisions that need a recommendation before engineering can scope. Each is genuinely open.

Runtime delivery — CDN-served single bundle vs. modular loader. Do we ship one ~30KB bundle that handles all CTA types, or a small loader (~5KB) that pulls in only the CTA renderers needed for the current page’s eligible CTAs? Modular is leaner per-page but adds latency on first impression. Recommend single bundle for V1 simplicity; modularize in V1.5 once we have telemetry.
Politogy Visitor ID cookie name and characteristics. First-party only; what cookie name (e.g., pvrm_vid) and what expiration (90 days? 1 year? 2 years?)? Recommend 1-year expiration with rolling refresh on visit, named pvrm_vid so it’s clearly Politogy’s and clearly visitor-scoped.
CTA configuration delivery mechanism. Polling vs. WebSocket vs. cache-with-versioning. Recommend: cache the config aggressively on first page load with a short TTL (60s) and a version hash, refresh in background; for instant deployment-to-live we can also push a tiny version-bump signal via a lightweight pub/sub channel in V1.5.
Trigger evaluation: client-side only vs. assisted server-side. Where do we evaluate behavioral triggers? Recommend client-side only in V1 — keeps the Runtime independent of server roundtrips, makes triggers feel instant. Server-side trigger augmentation (e.g., “show CTA only to UVPs with specific segment membership that just got recomputed”) in V1.5.
A/B testing variant assignment. Cookie-based sticky assignment vs. random per-page-load. Recommend cookie-sticky (assigned variant persists for the test duration) — without this, a returning visitor sees both variants and you can’t trust the data.
Inline Field submission UX on failure. When validation fails, inline field error UI vs. error toast vs. full-screen error state. Recommend inline (red border + below-field message) — fastest correction path; full-screen errors are anti-pattern for inline capture.
Embedded Survey state on CTA dismissal mid-flight. If visitor starts a 5-question embedded survey and dismisses at Q3, do we persist Q1-Q2 responses as a partial submission immediately, or only on completion? Recommend persist-on-each-question — every answer is a captured signal even if they abandon.
Conflict resolution: two CTAs eligible at once. What if Scroll-50% trigger fires for CTA A at the same moment Time-30s fires for CTA B? Recommend a CTA Priority field (1-10, configurable) where the highest priority wins; ties broken by created-date (newer wins, on the theory that newer is more strategically current).
Frequency cap scope. Per CTA, per CTA-version, or per account? Recommend per CTA-version per visitor — re-publishing a CTA after edits gives it a fresh impression budget, which matches user mental model.
Click-trigger element selection UX. How does a non-technical user pick “the visitor clicked this element”? Recommend a data-vrm-trigger="my-name" attribute that the user adds to their site, and the CTA references the trigger name. Avoid CSS selectors as the primary path — they break too easily on site edits.
Per-domain or per-account site list. Does an account register a list of domains it owns, or is the Runtime account-bound and any domain it lands on counts? Recommend explicit domain registration with a verification step (DNS TXT record or meta tag), prevents script hijacking and gives the customer visibility into where their CTAs are eligible to run.
Pre-conversion behavioral profile data volume. Recording every page view + scroll event + dismissal indefinitely per visitor produces a lot of data. Retention policy? Recommend: full granularity for 90 days, then roll up to summary metrics (page count, top pages, conversion event count) for longer-term storage.
Embedded Form/Survey: latest-version vs. pinned-version. If a CTA embeds Form X, and the user edits Form X later, does the CTA show the latest version or the pinned version-at-embed-time? Recommend latest-version (CTA always points at current live Form), with a warning at the Form edit screen if a Live CTA is currently embedding it.
Connection status detection accuracy. How do we tell the difference between “Runtime is installed but no visitors have hit the page yet” vs. “Runtime never installed”? Recommend: provide a one-click test page hosted by Politogy that the user visits from their own site browser, which generates a verification ping.
GDPR / cookie-consent integration. Do we gate the Visitor ID cookie behind the host site’s consent banner? Recommend: provide a JS API the host can call (window.vrm.consent.granted() / withheld()) and respect it; default to ungated for V1 with documentation pushing customers to integrate properly with their consent layer.
What “Engagement” means precisely. The funnel metric “engagements” needs a definition. Recommend: a CTA is “engaged” when any of — visitor clicks any button, focuses any inline field, hovers >2s on a Slide-in/Modal, or starts answering an embedded survey. Mere impression is not engagement.
A/B test conversion-attribution edge case. A visitor sees variant A on Monday, doesn’t convert, returns on Wednesday, gets variant A again (sticky), converts. Counted as Variant A conversion, fine. But what if their cookie cleared between visits — they get assigned Variant B on Wednesday, convert? Recommend attributing to the converting-session variant (B), accepting that cookie loss introduces small attribution noise.
Multi-CTA cooldown. Should there be a global “don’t show another CTA for N seconds after one was dismissed” rule? Recommend yes, default 60 seconds, configurable per account. Prevents the dreaded back-to-back popup spam pattern.

End of Spec

This document is the V1 conceptual specification for VRM CTAs in Relationship Mode. It is intentionally pared down to the conceptual layer; data model details, API surface, and Runtime engineering specifications follow in implementation specs derived from this document.

The North Star: install once, build CTAs in minutes, convert strangers in real time, capture every visitor’s behavioral history into the UVP. Everything that doesn’t serve that promise is deferred.

🗳️ Politogy VRM — V2 Specs

Explorer