> For the complete documentation index, see [llms.txt](https://docs.neonblue.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.neonblue.ai/data/snowflake-inbound.md).

# 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:**

```sql
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:**

```sql
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:**

```sql
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:**

```sql
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:**

```sql
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.