Snowflake Integration: Data Out

1. What this page is about

This page explains how Neon Blue shares data back to your Snowflake.

It is for teams who want to:

• Validate Neon Blue’s results in their own tools (e.g., Statsig, notebooks, dashboards)

• Combine Neon Blue experiments and personas with internal data for deeper analysis

• Create their own reporting or monitoring on top of Neon Blue outcomes

You do not need to know how the inbound integration works to read this, but the two are designed to complement each other.

---

2. Why we share data back to you

Neon Blue provides its own dashboards, but most teams also want:

• Warehouse-native analysis – running SQL directly on assignments and outcomes

• Consistency with internal metrics – verifying numbers against your existing definitions

• Custom views – slicing by your own segments, cohorts, or programs

To support that, Neon Blue exposes a Secure Data Share back to your Snowflake with:

• Raw assignment data (who saw what, when)

• Optional persona and preference tags

• Optional aggregate experiment metrics

You can treat this as a read-only source of truth for what Neon Blue did.

---

3. The outbound Snowflake share

From Neon Blue’s side:

• We create a Snowflake SHARE (e.g., CUSTOMER_OUTBOUND)

• We publish a small set of tables from our internal schema

• We grant your Snowflake account access

From your side:

• You create a database from that share (e.g., NEON_BLUE_OUTBOUND)

• You can query the shared tables like any other Snowflake tables

This outbound share is where you’ll find all the experimentation and personalization outputs that relate to your users.

---

4. Table: gate_assignments – who is in control vs Neon Blue

A gate is a decision point that determines whether a user receives:

• The legacy/control experience, or

• The Neon Blue experience (which might itself run an internal bandit or A/B test)

Examples of gates:

• “Is this user in the global Neon Blue program or global holdout?”

• “Should we use Neon Blue copy or legacy copy for this welcome flow?”

The gate_assignments table records these decisions.

Suggested schema:

SELECT *
FROM neon_blue_outbound.gate_assignments;

Typical columns:

• user_id – canonical user id

• gate_id – internal id for the gate

• gate_name – human-readable name (e.g., 'global_program_gate', 'welcome_flow_gate')

• variant_key – often 'control' or 'neon_blue'

• assigned_at – timestamp when the user entered the gate

• metadata – JSON field with additional context if needed

How you might use it:

• Compute revenue per user for variant_key = 'control' vs variant_key = 'neon_blue'

• Check holdout sizes, entrance counts, and long-term trends for each gate

• Layer on your own segments (e.g., first-time vs repeat customers)

---

5. Table: experiment_assignments – which creative variant each user saw

Within a gate, Neon Blue often runs experiments to test different creative variants:

• Email subject lines

• Email bodies or modules

• On-site banners or hero images

The experiment_assignments table records which variant each user is assigned to.

Suggested schema:

SELECT *
FROM neon_blue_outbound.experiment_assignments;

Typical columns:

• user_id – canonical user id

• experiment_id – internal experiment id

• experiment_name – e.g., 'welcome_email_subject', 'homepage_banner_q1'

• variant_id – internal variant id

• variant_name – e.g., 'control', 'value-focused', 'ingredient-focused'

• assigned_at – timestamp when user was first assigned the variant

• sticky – boolean indicating if the variant is sticky across exposures

• metadata – JSON with extra information (creative family, template references, etc.)

How you might use it:

• Join to your events and orders tables to compute:

  • Click-through rate by variant

  • Conversion rate by variant

  • Revenue per user by variant

• Compare Neon Blue’s reported metrics to your own calculations

• Build internal dashboards (e.g., in Looker, Mode, Tableau)

---

6. Table: persona_assignments (optional) – user-level preferences

Neon Blue can infer personas or preference clusters based on user behavior and experiment outcomes.

Examples:

• “Ingredient-conscious” vs “value-seeker”

• “Subscription-first” vs “one-time buyer”

• “Education-focused” vs “action-focused”

The persona_assignments table exposes these as user-level tags.

Suggested schema:

SELECT *
FROM neon_blue_outbound.persona_assignments;

Typical columns:

• user_id – canonical user id

• persona_id – internal persona id

• persona_name – human-readable label

• confidence_score – numeric value between 0 and 1

• updated_at – last update timestamp

• model_version – optional; indicates which persona model version produced this assignment

How you might use it:

• Segment reporting: compare performance by persona

• Build audiences in your ESP/CRM (after joining to user_messaging_id_map)

• Sanity check: do inferred personas match what you see qualitatively?

Important note: persona assignments are probabilistic. They get better as more data is collected. Use the confidence_score to filter or weigh analyses where necessary.

---

7. Optional aggregate metrics tables

In addition to raw assignments, Neon Blue can publish pre-computed metrics per experiment or gate.

An example table might look like:

Table: experiment_metrics

• experiment_id, experiment_name

• variant_id, variant_name

• metric_name – e.g., 'click_rate', 'conversion_rate', 'revenue_per_user'

• window – description of the measurement window (e.g., '7d_post_assignment')

• numerator, denominator

• metric_value

• baseline_variant_id, baseline_variant_name

• lift – relative to the baseline

These tables are convenient for quick looks and dashboards, but most analytical teams still prefer to compute their own metrics from raw assignments + their own events and orders. The outbound share supports both approaches.

---

8. Example: reproducing a gate-level revenue analysis

Here’s a simple example that computes 7-day revenue per user by gate variant using your own orders table.

WITH gate AS (
  SELECT
    user_id,
    gate_name,
    variant_key,
    assigned_at
  FROM neon_blue_outbound.gate_assignments
  WHERE gate_name = 'welcome_flow_gate'
),

orders_in_window AS (
  SELECT
    o.user_id,
    SUM(o.net_revenue) AS revenue_7d
  FROM orders o
  JOIN gate g
    ON o.user_id = g.user_id
   AND o.order_placed_at BETWEEN g.assigned_at
                             AND g.assigned_at + INTERVAL '7 day'
  GROUP BY 1
)

SELECT
  g.variant_key,
  COUNT(DISTINCT g.user_id) AS users_in_gate,
  COALESCE(SUM(o.revenue_7d), 0) AS total_revenue_7d,
  COALESCE(SUM(o.revenue_7d), 0) / NULLIF(COUNT(DISTINCT g.user_id), 0)
    AS revenue_per_user_7d
FROM gate g
LEFT JOIN orders_in_window o
  ON g.user_id = o.user_id
GROUP BY 1
ORDER BY 1;

This lets you:

• Check that Neon Blue’s reported lift matches what you compute

• Slice further by your own segments (e.g., new vs repeat, geography, subscription status) by joining gate to user_profiles

---

9. Example: analyzing experiment-level click-through rate

Similarly, for a subject line experiment:

WITH assignments AS (
  SELECT
    user_id,
    experiment_name,
    variant_name,
    assigned_at
  FROM neon_blue_outbound.experiment_assignments
  WHERE experiment_name = 'welcome_email_subject'
),

clicks AS (
  SELECT DISTINCT
    e.user_id,
    a.experiment_name,
    a.variant_name
  FROM neon_blue_inbound.events e
  JOIN assignments a
    ON e.user_id = a.user_id
   AND e.occurred_at BETWEEN a.assigned_at
                         AND a.assigned_at + INTERVAL '3 day'
  WHERE e.event_name = 'email_click'
)

SELECT
  a.variant_name,
  COUNT(DISTINCT a.user_id) AS users_exposed,
  COUNT(DISTINCT c.user_id) AS users_clicked,
  COUNT(DISTINCT c.user_id) / NULLIF(COUNT(DISTINCT a.user_id), 0)
    AS click_rate
FROM assignments a
LEFT JOIN clicks c
  ON a.user_id = c.user_id
GROUP BY 1
ORDER BY 1;

This uses:

• Outbound: experiment_assignments

• Inbound: events (email clicks)

and gives you a fully warehouse-native view of experiment performance.

---

10. Data cadence and retention

By default:

• Neon Blue updates outbound tables daily (or at an agreed cadence).

• Assignments are generally retained for the lifetime of the program (subject to your data retention policies and legal requirements).

This means you can:

• Backfill analyses as needed

• Re-evaluate experiments with new definitions (e.g., different attribution windows)

• Keep a historical view of how the program has evolved over time

---

11. How this fits into your workflow

A typical workflow for a data team looks like:

1. Neon Blue sets up the outbound Snowflake share with assignments and tags.

2. Your team creates a database from the share (e.g., NEON_BLUE_OUTBOUND).

3. You build a few initial SQL queries to reproduce key metrics using your own definitions.

4. Once you’re confident the pipelines line up, you:

   • Plug these tables into your BI / experimentation tools

   • Use Neon Blue personas and gates in internal reporting and segmentation

The goal is for Neon Blue to be present and visible in your warehouse, not a black box.