Snowflake Integration: Data In

1. What this page is about

This page explains how Neon Blue reads data from your Snowflake.

It covers:

• What Neon Blue needs from your warehouse

• How to structure the core tables

• How this fits into your existing data and reporting

You can read this even if you’ve never worked with Neon Blue before. The concepts match most modern analytics stacks.

---

2. Where this fits in the big picture

At a high level, the data flow looks like this:

1. Your systems (ecommerce platform, ESP, analytics) load data into your warehouse.

2. You expose a small, well-defined set of tables or views via a Snowflake Secure Data Share.

3. Neon Blue reads from that share to:

   • Learn how users behave

   • Measure experiments

   • Train and update personalization models

Separately (covered on the outbound page), Neon Blue can share results and assignments back to your Snowflake so you can validate and report internally.

---

3. What is a Snowflake Secure Data Share?

A Secure Data Share is Snowflake’s native way to share data between accounts without copying files around.

From your side:

• You create a SHARE (e.g., NEON_BLUE_SHARE)

• You add selected tables or views to that share

• You grant Neon Blue’s Snowflake account access

From our side:

• We create a database in our Snowflake account, sourced from your share

• We read the shared tables as if they were local, but we cannot modify your data

No S3 buckets, CSV exports, or SFTP are required. It’s secure, auditable, and versionable.

---

4. Data Neon Blue needs from you

To power experimentation and personalization, Neon Blue needs three core datasets:

1. Users – who your users are

2. Events – what users do

3. Orders / revenue – how business value shows up

Everything else (pageviews, attribution tables, etc.) is helpful but optional.

---

5. Core table: user_profiles (who your users are)

We covered this in the identifiers page, but we’ll restate the essential bits so this page stands alone.

Goal: One row per user with core attributes.

Example schema:

CREATE VIEW neon_blue_inbound.user_profiles AS
SELECT
  customer_id        AS user_id,
  email,
  created_at,         -- when they first gave you an email or created an account
  first_order_at,
  last_order_at,
  total_orders,
  total_revenue,
  segment_lifecycle,
  segment_value_tier
FROM analytics.customer_dim;

Key points:

• user_id is your canonical identifier

• created_at is when they enter your world, not just first purchase

• Include non-purchasers (signups, leads) so we can learn from early-funnel behavior

---

6. Core table: events (what users do)

The events table is a log of important user actions.

You do not need to send every single micro-event; focus on events that matter for measurement and modeling, such as:

• Email events (send, open, click, unsubscribe)

• Subscription events (start, pause, skip, cancel)

• Key onsite events (view important page, start checkout, complete onboard step)

• Other lifecycle events (survey completed, profile updated, etc.)

Recommended shape:

CREATE VIEW neon_blue_inbound.events AS
SELECT
  user_id,
  event_name,          -- e.g. 'email_click', 'email_unsubscribe', 'subscription_cancelled'
  occurred_at,         -- UTC timestamp
  source,              -- e.g. 'klaviyo', 'shopify', 'ga4'
  event_type,          -- e.g. 'positive', 'negative', or NULL
  value,               -- optional numeric; often NULL for simple binary events
  properties           -- VARIANT: JSON with extra fields (flow_name, template_id, etc.)
FROM analytics.event_fact;

Design tips:

• One row per event – if a user clicks twice, that’s two rows.

• Keep event_name consistent over time.

• Use properties to store contextual details instead of adding dozens of columns.

Neon Blue will map your events to:

• Optimization metrics – e.g., “Did the user click any email in this flow?”

• Guardrails – e.g., unsubscribes and spam complaints that we want to minimize

We’ll work with you to define which event names correspond to which “goal” and “negative” events per flow in a separate measurement configuration.

---

7. Core table: orders (revenue and purchases)

The orders table represents monetary outcomes. It allows Neon Blue to tie experiments back to real business value.

Example schema:

CREATE VIEW neon_blue_inbound.orders AS
SELECT
  order_id,
  user_id,
  order_placed_at,        -- when the order was created
  status,                 -- e.g. 'placed', 'shipped', 'cancelled', 'refunded'
  gross_revenue,
  net_revenue,
  currency,
  subscription_id,
  is_first_order,
  is_first_subscription_order
FROM analytics.order_fact;

We will align with you on:

• Whether to use gross_revenue or net_revenue as the primary metric

• How to treat cancellations, refunds, and skips, especially for subscriptions

• What measurement windows make sense (e.g., orders within 7 days of a given experiment assignment)

Neon Blue uses this table mainly for:

• Business-level reporting – e.g., “This experiment increased revenue per user by X%.”

• Sanity checks – verifying that upper-funnel improvements (clicks, etc.) translate into real revenue impact

---

8. Optional table: pageviews or web_events

If you have web analytics in Snowflake, you can share pageviews or web events to give Neon Blue richer signals, especially for new users.

Example schema:

CREATE VIEW neon_blue_inbound.pageviews AS
SELECT
  device_id,             -- e.g. GA4 user_pseudo_id
  user_id,               -- if known
  occurred_at,
  path,
  referrer,
  utm_source,
  utm_medium,
  utm_campaign,
  user_agent,
  properties             -- VARIANT with extra metadata
FROM analytics.pageview_fact;

How Neon Blue uses this:

• To understand which pages users look at before converting

• To infer early preferences (e.g., browsing baby wipes vs baby lotion)

• As a feature for persona modeling and creative targeting

If user_id is not available on a given row, the device_id can be joined through your user_device_id_map table when the association becomes known.

---

9. Optional table: user_attribution

If you already maintain a marketing attribution table (e.g., first-touch or last-click per user), we can use it as a model feature.

Example schema:

CREATE VIEW neon_blue_inbound.user_attribution AS
SELECT
  user_id,
  attribution_model,     -- e.g. 'first_touch_ga4', 'last_click_internal'
  source,
  medium,
  campaign,
  adgroup,
  creative,
  attributed_at
FROM analytics.user_attribution_dim;

Neon Blue is agnostic to which attribution model you choose. The important thing is that it reflects how your team actually thinks about acquisition sources.

---

10. Data freshness and historical depth

Freshness:

• For most lifecycle programs, a daily update is sufficient

• If you want more real-time dashboards, we can align on hourly or intra-day updates

Historical depth:

• For initial setup, we recommend 6–12 months of history if available

• Longer history is a plus, particularly for subscription businesses and long funnels

---

11. Putting it all together: a simple end-to-end use case

Let’s say you want Neon Blue to optimize your Abandoned Cart flow.

With the inbound integration in place:

1. Your events table tells us:

   • When a user abandoned a cart

   • When they received a recovery email

   • Whether they clicked or unsubscribed

2. Your orders table tells us:

   • Whether that user placed an order after the recovery email

   • How much revenue was generated

3. Your user_profiles table tells us:

   • When the user joined

   • Whether they’re a new customer or repeat buyer

Neon Blue uses this data to:

• Test multiple creative variants for the recovery email

• Learn which variants work best for different user types

• Report how much incremental revenue those variants drive

All powered by the three core tables you’re sharing into the inbound Snowflake integration.