Lead Capture Panel

Lead capture is opt-in. If you switch it on for a quiz, shoppers see an email field at a point you choose; their email and consent metadata land in dd_leads and (optionally) get pushed to your CRM or webhook.

If you switch it off, no email is collected at all. The recommendation panel renders straight after the last question.

Turning it on

Open the Connect tab in the Builder for the quiz you want. Toggle Enable lead capture.

[SCREENSHOT: The Connect tab with the Enable lead capture toggle and the placement dropdown.]

You then pick:

• Placement — where in the flow the email field appears.
• Required vs optional — whether shoppers can skip the field and still see results.
• Consent text — the small copy block under the email input.

Placement options

Three placements, all configurable in the Connect tab:

Placement	Where shoppers see it	When to use it
Inline	The email field appears as one of the questions in the flow.	When the email itself is part of the conversation (“Where shall we send the recommendation?”).
Modal	A modal pops up after the last question, before the results panel renders.	When you want a clear gate without redesigning the flow.
After results	The field appears below the results panel as a “Save your results” prompt.	When you want results to be a freebie and the email to be the conversion.

The default is after results — the lightest-touch placement.

Required vs optional is a UX call, not a security one

Marking the field required stops shoppers from seeing results until they enter an email. That’s a strong conversion tactic but a bouncy one — some shoppers will leave. Optional lets everyone see results and captures email from the ones who choose to share it. Test which works for your audience.

The consent text slot

Below the email input, you can render a short consent statement — typically two lines of opt-in language linking to your privacy policy. The slot accepts plain text plus a single link; HTML is sanitised.

The consent text is part of the published snapshot, so it versions with the quiz. If you republish with new copy, sessions that started before the publish keep the old copy; new sessions get the new copy.

What happens when a shopper submits

1. The storefront POSTs the email and consent state to POST /storefront/sessions/{sid}/lead.
2. The endpoint writes a row to dd_leads carrying both the plaintext email (used for CSV export and outbound integrations) and a keyed HMAC-SHA256 email_hash (used for fast dedupe lookups). The hash key is the per-site secret generated at activation.
3. The dino_discover_lead_captured action fires with (int $lead_id, int $session_id, string $email).
4. If any integrations are enabled (Klaviyo, Mailchimp, webhook), the push is queued on Action Scheduler and runs off the request path — the shopper’s results render immediately.

The email_hash column lets the plugin de-duplicate leads and serve GDPR Article 15 lookups without scanning plaintext, but the plaintext email is also on the row — treat dd_leads as PII at rest and back it up with the same protections as any customer table.

Integrations

Three ship today, configured per-quiz on the Connect tab:

Klaviyo

Pushes the lead to a Klaviyo profile and (optionally) adds the profile to a list. Configure with:

• Your Klaviyo API key (encrypted at rest with the activation-generated key).
• The list ID to add the profile to.
• (Optional) Custom property keys to map session metadata onto the Klaviyo profile.

Click Test to send a synthetic event to Klaviyo and confirm the key works.

Mailchimp

Pushes the lead to a Mailchimp audience. Configure with:

• Your Mailchimp API key (encrypted at rest).
• The audience ID.
• (Optional) Merge field mappings.

Click Test to confirm.

Webhook

POSTs a JSON payload to a URL you control. Configure with:

• The endpoint URL.
• (Optional) An HMAC secret for request signing.
• (Optional) A retry policy override.

Useful for routing leads into a tool we don’t have a native integration for yet — your CRM, a Slack channel, a Google Sheet via Zapier, etc.

Fallback API keys at the site level

If you operate many quizzes against the same Klaviyo or Mailchimp account, you can set a site-wide fallback API key in Settings. Per-quiz configs that don’t override the key inherit the fallback.

The fallback keys are filterable for hosting environments that prefer to source them from environment variables:

• dino_discover_klaviyo_fallback_api_key
• dino_discover_mailchimp_fallback_api_key

See Hook Reference for the signatures.

Reviewing captured leads in the admin

There’s no top-level “Leads” admin page in the 0.1.0 Beta. Instead:

• The Metrics tab on each quiz shows the lead-capture rate.
• The REST endpoint GET /wp-json/dino-discover/v1/leads returns the list (admin-only).
• GET /wp-json/dino-discover/v1/leads/export.csv streams a CSV. A one-click CSV-download button in the Connect tab is on the Beta gap list.

GDPR — exporter and eraser

Dino Discover is a registered participant in WordPress’s privacy tools:

• Tools → Export Personal Data returns the lead row, the session row, and the event log for any email address that’s been captured.
• Tools → Erase Personal Data removes the same rows on request.

So if a shopper exercises their GDPR Article 15 (access) or Article 17 (erasure) rights, the standard WordPress flow handles it.

What’s next

• Embedding the Quiz — where lead capture lives in the broader storefront story.
• Results & Recommendations — the panel that renders alongside or after the lead form.
• Settings — fallback API keys and consent template settings.
• Hook Reference — the lead_captured action and integration filters.