# Audience Signals
Source: https://docs.innkeepr.ai/concepts/audience-signals
## Overview
Audience Signals are predictive user segments built from **treatment effect** scores. They identify users by predicted incremental response—who will convert because of your ads, not just who looks similar to past converters.
Audience Signals sync directly to advertising platforms through native APIs, enabling lookalike expansion, direct targeting, and spend suppression without manual exports.
## Prerequisites
**Data Requirements**
Audience Signals require three data inputs for treatment effect modeling:
**Event data** – Behavioral interactions (page views, product views, add-to-cart, purchases, signups) from:
* Innkeepr.js (client-side tracking)
* Server-side APIs (backend events, transaction data)
* CDP integrations (Segment, RudderStack, mParticle, Braze)
* Data warehouses (BigQuery, Snowflake, Redshift)
**Treatment exposures** – Marketing touchpoint data showing which users were exposed to which treatments, captured through:
* UTM parameters (automatically parsed)
* Platform click IDs (gclid, fbclid, ttclid)
* Referrer data and campaign identifiers
**User identifiers** – Matching keys for signal activation:
* First-party cookies (anonymous tracking)
* User IDs (logged-in users)
* Email addresses (hashed for platform matching)
**Timeline**
| Milestone | Duration |
| :------------------------ | :------------------------------- |
| Initial model training | 30+ days of historical data |
| First audience generation | 24-48 hours after configuration |
| Audience refresh | Every 1-3 days depending on type |
## Use Cases
Innkeepr supports three primary use cases for Audience Signals:
**Seed Audiences – Acquisition/Lookalikes**
High-incrementality user lists used to seed lookalike audiences. Platforms use these seeds to find similar prospects, improving acquisition efficiency.
**Retargeting Audiences – Re-engagement**
Users with high predicted recovery or repeat purchase probability. These segments identify users who interacted with your brand but haven't converted, and who are predicted to respond incrementally to retargeting.
**Exclusion Audiences – Spend Protection**
Low or negative-incrementality users (bottom 20-40% by predicted lift). These audiences should be excluded from campaigns to suppress wasted spend on users unlikely to convert incrementally.
## Setup Instructions
**Step 1: Define Your Objective**
The objective function defines what business outcome your signals optimize for. All treatment effect predictions - and therefore all audience segments - maximize incremental impact on this objective.
Examples:
* Purchase probability within 7 days of ad exposure
* 90-day CLV for new customers
* Signup likelihood for free trial visitors
* Repeat purchase probability for existing customers
Multiple objectives can run in parallel for different signal strategies.
Learn more
* [Objectives](/concepts/objectives)
**Step 2: Configure Audience Segments**
Configure segments based on treatment effect score distributions:
1. **Select audience type** – Choose your signal strategy:
* Acquisition seeds (top 10-20% by predicted lift)
* Exclusion audiences (bottom 20-40% by lift or negative effects)
* Retargeting segments (high recovery probability)
2. **Link objective** – Select the objective this audience optimizes for
3. **Set treatment context (optional)** – Specify which historical campaigns this audience learns from. Linking past campaigns enables faster pattern recognition.
**Step 3: Activate Across Destinations**
Audience Signals sync directly to connected platforms through native APIs.
**Supported destinations:**
| Platform | Supported Features |
| :------------ | :---------------------------------------------------------------------------------------------- |
| Meta Ads | Custom audiences, value-based audiences, lookalike seeding, exclusions, retargeting |
| Google Ads | GA4 audiences, Customer Match, exclusions |
| TikTok Ads | Custom audiences, lookalike seeding, exclusions (email matching only) |
| Amazon Ads | DSP segments, Marketing Cloud integration |
| Criteo | Custom segments, prospecting, retargeting, exclusions |
| CRM platforms | Treatment effect scores as user attributes, segment-based automation (Klaviyo, Braze, Iterable) |
Learn more
* [How to Set Up Audience Signals on Meta](/guides/how-to-guides/meta)
* [How to Set Up Audience Signals in Performance Max](/guides/how-to-guides/pmax)
* [How to Set Up Audience Signals on TikTok](/guides/how-to-guides/tiktok)
## Best Practices & Optimization
**Segment Configuration**
* Start with broader segments (top 20-30%) and narrow based on performance data
* Use separate audiences per objective - don't mix CLV and conversion likelihood segments
* Refresh exclusion audiences more frequently (daily) than acquisition seeds (every 2-3 days)
**Testing Recommendations**
* Test audience signals incrementally against existing targeting using control/test campaign structures
* Allow 2-3 model training cycles (4-6 weeks) before evaluating signal quality
* Compare performance against traditional broad, behavioral or demographic audiences
**Common Pitfalls**
* **Using exclusion audiences for targeting** - these are optimized to identify non-incremental users
* **Evaluating too early** - signal accuracy improves after initial training cycles
* **Overlapping audiences** - ensure seed and exclusion segments don't compete in the same campaigns
## Troubleshooting
**Audience Not Populating**
Issue: No users in audience after 48 hours
Solutions:
* Verify sufficient event data is flowing (minimum 5,000 monthly sessions)
* Check that user identifiers are being captured correctly
* Confirm platform connection is active and permissions are granted
**Low Match Rates**
Issue: Platform audience size is significantly smaller than Innkeepr audience
Solutions:
* For email-matched audiences: Verify email formatting and hashing
* For pixel-based audiences: Ensure users have visited your website
* Allow 24-48 hours for full platform matching to complete
**Signal Quality Issues**
Issue: Audience performance doesn't improve over baseline
Solutions:
* Verify objective function aligns with actual business goals
* Check that sufficient conversion volume exists (300+ monthly conversions recommended)
* Allow more training cycles - early models have wider confidence intervals
Learn more
* [Signal Overview](/concepts/signals)
* [Conversion Signals](/concepts/conversion-signals)
* [Objectives](/concepts/objectives)
* [How to Set Up Audience Signals on Meta](/guides/how-to-guides/meta)
* [How to Set Up Audience Signals in Performance Max](/guides/how-to-guides/pmax)
* [How to Set Up Audience Signals on TikTok](/guides/how-to-guides/tiktok)
* [Spec: Identify](/connections/spec-identify)
# Conversion Signals
Source: https://docs.innkeepr.ai/concepts/conversion-signals
## Overview
Conversion Signals are **incrementality-weighted** conversion values sent to advertising platforms. Instead of passing raw transaction amounts to bidding algorithms, Innkeepr adjusts conversion values based on each touchpoint's incremental conversion contribution.
## Prerequisites
**Data Requirements**
Conversion Signals require four data inputs for treatment effect modeling and value adjustment:
**Event data** – Behavioral interactions including conversion events with values (purchases, signups, subscriptions) from:
* Innkeepr.js (client-side tracking)
* Server-side APIs (backend events, transaction data)
* CDP integrations (Segment, RudderStack, mParticle, Braze)
* Data warehouses (BigQuery, Snowflake, Redshift)
**Treatment exposures** – Marketing touchpoint data showing which users were exposed to which treatments, captured through:
* UTM parameters (automatically parsed)
* Platform click IDs (gclid, fbclid, ttclid)
* Referrer data and campaign identifiers
**Conversion values** – Transaction amounts or value proxies:
* Order values (revenue, margin, or custom value)
* Lead scores or qualification values
* Subscription values (monthly, annual, LTV-based)
**User identifiers** – Matching keys for attribution:
* First-party cookies (automatically collected by innkeepr.js)
* User IDs and email addresses (sent via innkeepr.identify())
Learn more
* [Spec: Identify](/connections/spec-identify)
**Timeline**
| Milestone | Duration |
| :--------------------------- | :------------------------------ |
| Initial model training | 30+ days of historical data |
| Signal activation | Immediate after configuration |
| Model stabilization | 2-3 training cycles (4-6 weeks) |
| Bidding algorithm adaptation | 14-30 days after activation |
## Use Cases
Innkeepr supports three primary use cases for Conversion Signals:
**Value-Weighted Bidding**
Adjust conversion values based on incremental touchpoint contribution, training platform algorithms to bid higher for users with high **treatment effects** and lower for users who would likely convert without ad exposure.
Example: A €100 order from a user with 80% predicted incremental lift passes as €80. A €100 order from a user with 30% predicted lift passes as €30.
Best for: Campaigns optimized for value (tROAS, value-based bidding) where incremental revenue matters more than total attributed revenue.
**Incrementality-Aware CPA**
Optimize cost-per-acquisition toward truly incremental conversions by reshaping the **conversion signal stream**. Instead of weighting individual conversions, Innkeepr removes low-incrementality conversions that would have happened without ad exposure and adds synthetic conversion events for high-value sessions that didn't convert but demonstrated strong incremental response.
Example: A user converts after an ad click but had high baseline purchase intent—this conversion is removed from the signal stream. Meanwhile, a session that didn't convert but showed strong incremental engagement receives a synthetic conversion event, training the algorithm to value similar sessions.
Best for: Campaigns optimized for conversions (tCPA) where true incremental acquisition matters more than attributed conversion counts.
**Step 1: Verify Platform Integration**
Conversion Signals are delivered through Innkeepr's platform integrations. Verify the following connections are active:
1. **Meta:** Pixel integration with innkeepr\_conversion event configured
2. **Google:** Offline conversion upload via Google Ads API
3. **TikTok:** Pixel integration with conversion events configured
4. **Amazon:** Attribution events via Marketing Cloud
Learn more
* [How to Set Up Conversion Signals on Meta](/guides/how-to-guides/meta)
* How to Set Up Conversion Signals on Google Ads
* [How to Set Up Conversion Signals on TikTok](/guides/how-to-guides/tiktok)
**Step 2: Define Your Objective**
The objective function defines what outcome Conversion Signals optimize for. Treatment effect calculations - and therefore value adjustments - maximize incremental impact on this objective.
Examples:
* Revenue within 7 days of ad exposure
* 90-day CLV for new customers
* Subscription value for trial conversions
* Margin-adjusted order value
Learn more
* [Objectives](/concepts/objectives)
**Step 3: Select Optimization Type**
1. Choose how Innkeepr optimizes your conversion signals:
* **Conversion optimization** – Reshapes the conversion event stream to train platform algorithms toward incremental conversions. Low-incrementality conversions are removed; synthetic events are added for high-value sessions.
* **Conversion value optimization** – Adjusts conversion values based on predicted treatment effects. High-incrementality conversions pass full value; low-incrementality conversions pass reduced values.
2. Choose based on your bidding strategy: conversion optimization for tCPA campaigns, conversion value optimization for tROAS campaigns.
**Step 4: Activate Platform Delivery**
Connect Conversion Signals to destination platforms:
| Platform | Integration Method | Delivery |
| :--------- | :------------------------------------ | :-------------------- |
| Meta Ads | Events API (CAPI) | Real-time server-side |
| Google Ads | Enhanced Conversions / Google Ads API | Real-time or batch |
| TikTok Ads | Events API | Real-time server-side |
| Amazon Ads | Attribution events | Batch postbacks |
**Step 5: Validate Signal Delivery**
After activation, verify signals are received correctly:
1. Check platform event managers for incoming events
2. Compare Innkeepr-sent values against platform-reported values
3. Verify event **deduplication** is working (no double-counting)
4. Monitor delivery success rates in Innkeepr dashboard
## Best Practices & Optimization
**Testing Recommendations**
* Run A/B tests comparing incrementality-weighted signals against raw conversion values
* Use campaign splits: control campaign with standard tracking, test campaign with Conversion Signals
* Allow 30-60 days for platform algorithms to adapt to new value distributions
**Platform-Specific Considerations**
* **Meta:** Pixel signals should include all standard parameters (`event_id`, `user_data`) for optimal matching
* **Google:** Enhanced Conversions require hashed user data for identity matching
* **TikTok:** Events API requires consistent event naming across web and server-side
**Common Pitfalls**
* **Not allowing sufficient learning time** - platforms need 2-4 weeks to adapt bidding to new value distributions
* **Misaligned objectives** - ensure the objective function matches your actual business goal
## Troubleshooting
**Signals Not Appearing in Platform**
Issue: Conversion events not showing in platform event manager
Solutions:
* Verify server-side tracking is correctly implemented
* Check API credentials and permissions
* Confirm event naming matches platform expectations
* Review Innkeepr delivery logs for failed requests
**Value Mismatch Between Innkeepr and Platform**
Issue: Platform-reported values differ from Innkeepr-sent values
Solutions:
* Check for currency conversion differences
* Review value rounding or truncation in platform settings
**Low Match Rates**
Issue: Platform matching fewer conversions than expected
Solutions:
* Verify user identifiers (email, phone) are correctly hashed
* Ensure all ad accounts have been connected to Innkeepr
* Ensure first-party cookies are being captured
* Review platform identity matching requirements
**Signal Quality Issues**
Issue: Conversion signals performance doesn't improve over baseline
Solutions:
* Ensure all ad accounts have been connected to Innkeepr
* Verify objective function aligns with actual **business goals**
* Check that sufficient conversion volume exists (300+ monthly conversions recommended)
* Allow more training cycles - early models have wider confidence intervals
Learn more
* [Signal Overview](/concepts/signals)
* [Audience Signals](/concepts/audience-signals)
* [Objectives](/concepts/objectives)
* [Meta CAPI Setup](/guides/how-to-guides/meta)
* Google Enhanced Conversions Setup
* [TikTok Events API Setup](/guides/how-to-guides/tiktok)
* [Spec: Identify](/connections/spec-identify)
# An Introduction to Innkeepr
Source: https://docs.innkeepr.ai/concepts/introduction
This page provides a high-level overview of Innkeepr—what it is, how it works, and where it fits in your marketing infrastructure. For implementation details and API documentation, skip to the technical guides.
## What is Innkeepr?
Innkeepr is the **signal optimization** platform that sits between your customer data and marketing stack. We transform behavioral data into incrementality-optimized **audience** and **conversion signals** that make platform algorithms smarter.
Just as Segment unified customer data across your stack, Innkeepr makes your marketing stack **incrementality-aware**. Collect interaction data from websites, apps, and backend systems—then activate it as causal signals that flow directly into Google, Meta, TikTok, Amazon, and other platforms.
## What does it do?
Innkeepr processes first-party behavioral data through **causal AI** to generate two types of signals:
[**Audience signals**](/concepts/audience-signals) identify users most likely to deliver incremental value—enabling platforms to reach high-impact segments through lookalike expansion or exclude low-value traffic before budget is spent.
[**Conversion signals**](/concepts/conversion-signals) weight each conversion by its incremental contribution—training bidding algorithms to optimize for true business impact rather than baseline behavior.
These signals sync automatically to connected platforms. No manual exports, no CSV uploads, no repeated audience builds. Once configured, Innkeepr continuously streams incrementality-optimized signals to your marketing stack.
## How does Innkeepr work?
Capture behavioral events from client-side tracking ([Innkeepr.js](/getting-started/getting-started-guide#install-innkeepr-js)), server-side APIs, or data warehouse sources. Events flow into Innkeepr's processing layer with user context, product metadata, and marketing touchpoint exposure.
Define what matters to your business—CLV, purchase probability, retention, new customer acquisition. Innkeepr optimizes signals for these specific outcomes, not generic engagement metrics.
Our engine evaluates each user based on predicted incremental impact—isolating the causal effect of marketing touchpoints from baseline behavior. This means every signal reflects true incrementality, not just correlation with conversions.
Transform causal predictions into activation-ready signals:
\- **Audience signals:** Predictive segments for targeting or exclusion
\- **Conversion signals:** Incrementality-weighted conversion values for bidding optimization
Signals sync directly to connected destinations:
\- Media platforms: Google Ads, Meta, TikTok, Amazon, Criteo
- Lifecycle tools: Klaviyo, Braze, Iterable
- Data infrastructure: Snowflake, BigQuery, S3
Signals update automatically as new behavioral data arrives. No manual maintenance, no stale audiences, no batch processing delays.
## Core concepts
### [Objectives](/concepts/objectives)
Measurable business outcomes that define what Innkeepr optimizes for: customer lifetime value, purchase probability, retention likelihood, new customer acquisition. Define multiple objectives to optimize different growth surfaces or run parallel analyses.
### Treatment effects
Quantified incremental impact of marketing touchpoints (ad sets, campaigns, channels) on defined business objectives. Treatment effects isolate what marketing caused versus what would have happened anyway—forming the foundation for all signal generation.
### [Audience signals](/concepts/audience-signals)
Custom audience segments built from **treatment effect** predictions. Use them to seed lookalikes with high-incrementality users, suppress spend on low-lift traffic, or target segments by predicted CLV contribution. Syncs as Custom Audiences (Meta), Customer Match (Google), or equivalent formats across platforms.
### [Conversion signals](/concepts/conversion-signals)
Conversion values adjusted by **incremental contribution**. Instead of passing raw transaction amounts to platform algorithms, Innkeepr weights each conversion based on its predicted lift over baseline—ensuring bidding optimizes for causation, not correlation.
## Destinations
Innkeepr connects directly to your marketing and data infrastructure:
* **Media platforms:** Meta Ads, Google Ads, TikTok Ads, Amazon Ads, Criteo
* **Lifecycle marketing:** Klaviyo, Braze, Iterable, Customer.io
* **Data warehouses:** Snowflake, BigQuery, Redshift, S3
* **E-commerce platforms:** Shopify, WooCommerce, Magento
Signals flow through standard platform APIs—Custom Audiences, Customer Match, conversion events, and offline conversion uploads. No custom integrations or middleware required.
Common use cases
* **New customer acquisition** - Build lookalike audiences from high-incrementality converters instead of all converters—expanding reach into segments most likely to deliver acquisition lift.
* **Spend suppression** - Exclude users predicted to have low or negative incremental value before budget is wasted—reducing CAC by focusing on high-impact traffic only.
* **CLV optimization** - Weight conversion values by predicted lifetime value contribution so platform bidding algorithms optimize for long-term profitability, not just immediate revenue.
* **Cross-platform consistency** - Activate the same incrementality-optimized signals across Google, Meta, TikTok, and Amazon—ensuring all platforms work from a unified causal foundation rather than fragmented correlation-based targeting.
* **Lifecycle personalization** - Power email, SMS, and push campaigns with the same treatment effect scores that guide paid media—aligning owned and paid channel strategies around shared incrementality insights.
## Privacy & governance
Innkeepr is **privacy-first** infrastructure. The platform supports:
* Flexible data ingestion controls and PII handling policies
* Configurable identity resolution (anonymous, pseudonymous, or known users)
* Compliance frameworks: GDPR, CCPA, PIPEDA
* Data isolation: your data never mixes with other customers or trains shared models
* Granular access controls and audit logging
All signal generation happens within your **workspace**. Innkeepr processes behavioral data to create signals—it doesn't store or share raw **PII** with platforms beyond what's required for audience matching.
Learn more
* **[Getting started:](/getting-started/getting-started-guide)** Follow the setup guide to connect your first connection and define an objective
* **Implementation:** Review the tracking specification for event structure and properties
* **[Use cases:](/getting-started/use-cases/overview)** Explore pre-built configurations for common business objectives
* **API reference:** Dive into technical documentation for server-side implementation
# Objectives
Source: https://docs.innkeepr.ai/concepts/objectives
An **Objective** defines the business outcome a Signal optimizes for. Every Audience Signal and Conversion Signal is linked to an objective, and Innkeepr's causal engine ranks users by their predicted incremental impact on that objective.
Common objectives include conversion likelihood, customer lifetime value (CLV), lead qualification, and other custom outcomes built from tracked events or calculated traits.
## Objective Definition
Here's an example objective definition:
```json theme={null}
{
"name": "New Customer Revenue",
"events": ["checkout_completed"],
"filters": [],
"aggregation": "value",
"target_trait": "order_value",
"direction": "maximize",
"per": "user",
"horizon": "30d"
}
```
| Field | Type | Description |
| :------------- | :----- | :-------------------------------------------------------------------------------------------------------------------- |
| `name` | String | Name of the objective (freely definable) |
| `events` | Array | Event types (e.g. `checkout_completed`) used to calculate the objective value |
| `filters` | Array | Optional filter conditions to narrow the objective to relevant events or users |
| `aggregation` | String | How the objective value is aggregated across matching events — `count` (number of events) or `value` (sum of a trait) |
| `target_trait` | String | Required when `aggregation` is `value`: the numeric event property to aggregate (e.g. `order_value`) |
| `direction` | String | Direction to optimize for: `maximize` or `minimize` |
| `per` | String | Aggregation level: `user`, `session`, or `group` |
| `horizon` | String | Observation window over which the objective is measured |
**Note:** Filter syntax is documented separately.
Multiple objectives can be defined and versioned independently, and filtered by additional traits — for example "CLV for new customers in EU markets" or "7-day retention from paid social traffic." Multiple objectives can run in parallel for different signal strategies.
Learn More
* [Audience Signals](/concepts/audience-signals)
* [Conversion Signals](/concepts/conversion-signals)
# Signals Overview
Source: https://docs.innkeepr.ai/concepts/signals
## What Are Signals?
Signals are predictions derived from Innkeepr's **causal models** and come into two different forms:
* [Audience Signals](/concepts/audience-signals) – Predictive user segments for targeting, lookalikes, and exclusions
* [Conversion Signals](/concepts/conversion-signals) – Incrementality-weighted conversion values to enhance bidding systems
Both signal types are powered by Innkeepr's **causal engine**, which estimates the true incremental impact of your marketing touchpoints.
## How Signals Work
**Data**
Innkeepr collects behavioral data through client-side tracking ([innkeepr.js](/getting-started/getting-started-guide#install-innkeepr-js), server-side APIs, and warehouse connections. This data is processed into time-series user sessions containing interaction sequences, temporal context, marketing exposure, and user attributes.
**Objectives**
Signals are optimized for specific business outcomes defined through objective functions - the measurable results you want to drive, they are called *Objectives*
Common objectives include:
* **Conversion likelihood** – Binary outcomes like purchases, sign-ups, or installs
* **Customer lifetime value (CLV)** – Predicted value over 90 or 180 days
* **Lead qualification** – MQL probability based on engagement and firmographic data
* **Custom objectives** – Any measurable outcome from tracked events or calculated traits
Objectives can be filtered by additional traits, such as "CLV for new customers in EU markets" or "7-day retention from paid social traffic."
Learn More
* [Objectives](/concepts/objectives)
**Treatments & Attribution**
Treatments represent marketing touchpoints - ad clicks, email opens, campaign landing page visits. Innkeepr uses **7-day first-touch** attribution to assign treatment exposure to user sessions based on UTM parameters, referrer data, and platform click IDs.
Treatments map to platform-native campaign structures: ad sets (Meta), ad groups (Google/TikTok), and asset groups (Performance Max). This granularity reveals which specific campaign elements drive the most **incremental lift**.
Treatment data is the foundation for signal learning. The causal engine observes which users were exposed to which treatments and what outcomes they achieved, then estimates individual treatment effects - the predicted incremental impact of a marketing treatment on a user's likelihood to reach an objective.
Treatment effects answer: *"If this user sees this ad, how much will their conversion probability increase compared to baseline?"*
## Signal Types
**Audience Signals**
Audience signals are predictive user segments built from **treatment effect** scores. They identify users most (or least) likely to deliver incremental value from marketing exposure.
**Use cases:**
* **Seed audiences** – High-incrementality users (top 10-20%) for lookalike expansion
* **Exclusion audiences** – Low-incrementality users to suppress wasted spend
* **Retargeting audiences** – Users predicted to respond incrementally to re-engagement
Learn more
* [Audience signals](/concepts/audience-signals)
**Conversion Signals**
Conversion signals adjust conversion values by incremental contribution. Instead of passing raw transaction amounts to platform algorithms, Innkeepr weights each conversion based on its predicted lift over baseline.
**How it works:** When a €100 conversion occurs and the predicted treatment effect indicates 60% **incremental lift**, the signal passes €60 as the incrementality-weighted value. This trains bidding algorithms to prioritize users and touchpoints that deliver true causal impact.
Learn more
* [Conversion signals](/concepts/conversion-signals)
**Signal Quality Over Time**
As more **behavioral data** flows through Innkeepr, treatment effect models become more precise. Early implementations may have wider confidence intervals; after 2-3 model training cycles (4-6 weeks), predictions stabilize and signal quality improves measurably.
**Monitoring**
Innkeepr tracks signal health through **prediction accuracy**, audience overlap rates, conversion signal delivery rates, and model confidence scores.
# Connections Overview
Source: https://docs.innkeepr.ai/connections/overview
Connections are how you build integrations to Innkeepr. With Connections you can collect **event data** from your mobile apps, websites, and servers with one API, pull in contextual data from cloud apps, CRM, payment systems, and internal databases and downstream signals into your marketing stack.
## Connections
In Innkeepr, you define a **connection** for each distinct stream of customer interaction data - typically one for each website, mobile app, or backend service you want to track. While it’s not strictly required, we strongly recommend setting up a **separate connection for each unique origin of data** to keep your data pipeline clean and manageable.
Each connection belongs to a specific **workspace** and has its own dedicated URL in this format:
[https://app.innkeepr.ai/your-workspace/connections/your-connection-name/](https://app.innkeepr.ai)
You can create new connections directly from your workspace dashboard. Each connection you set up will generate a **write key**, which you’ll use to send event data into the system. For example, if you’re embedding our JavaScript SDK (Innkeepr.js) into your frontend, the setup snippet provided in our Quickstart Guide includes this write key so that events are routed correctly.
## Destinations
**Destinations** in Innkeepr are your growth and marketing tools - like Meta Ads, Google Ads, LinkedIn, or any other platform where you can **activate audience** or **conversion signals**.
You define your audiences and conversion signals once, and Innkeepr takes care of translating and syncing them downstream, automatically adapting to the requirements of each platform. Whether you’re syncing high-intent product-qualified leads to Meta Ads, sending churn-prevention audiences to LinkedIn, or pushing purchases to Google Ads for conversion tracking - Innkeepr ensures that your signals arrive correctly formatted
You can browse and enable destinations from Innkeepr’s **connection catalog**, and once activated, data begins flowing in real-time - no extra engineering needed.
Explore the [destinations page](https://app.innkeepr.ai/connections) for the full list and find the right integrations for your growth stack.
# Google Analytics 4
Source: https://docs.innkeepr.ai/connections/sources/ga4
* The Google Analytics 4 Audience Connection is an **Audience Signal and Cloud connection**. This means it syncs audience segments to your GA4 property, where they become available for targeting in linked Google Ads accounts.
This connection combines Innkeepr's incremental prediction models with Google's native audience infrastructure. This allows you to sync Audience Signals from Innkeepr to GA4 so that you can target high-value users in Performance Max and other Google Ads campaigns. Audiences sync automatically to your GA4 property and flow through to any linked Google Ads accounts.
## Getting Started
1. From your workspace's /connections page, click **add connection**.
2. Choose **Google Analytics 4**.
3. Click **Create** and **Continue** then Connect to OAuth into Google.
4. Select which properties you would like to sync (you may change this selection later).
5. Select your Property ID from the dropdown.
6. Enter your Measurement ID (e.g., `G-XXXXXXXXXX`).
7. Enter your **API Secret** for the Measurement Protocol.
8. Click **Verify** to confirm Google Signals is activated on your property.
9. Click **Finish**.
## How Innkeepr Syncs Audiences
Innkeepr syncs audience signals to GA4 automatically based on audience type:
Audience Type Sync Frequency
| Audience Type | Sync Frequency |
| :-------------------- | :------------- |
| Seed Audiences | Every 3 days |
| Exclusion Audiences | Daily |
| Retargeting Audiences | Daily |
When Innkeepr syncs an audience to GA4:
* **New users** matching the audience criteria are added to the GA4 audience
* **Users who no longer qualify** are removed on the next sync cycle
* **Audience membership** is determined by Innkeepr's treatment effect models at each sync interval
Audiences created by Innkeepr appear in GA4 with the following naming convention:
`[Innkeepr] ()`
For example:
`[Innkeepr] High-Value Prospects (Seed)`
`[Innkeepr] Recent Converters (Exclusion)`
`[Innkeepr] Cart Abandoners (Retargeting)`
Upon subsequent syncs, Innkeepr updates only users whose audience membership has changed—users who newly qualify are added, and users who no longer qualify are removed.
Learn more
* [Audience Signals](/concepts/audience-signals)
* [How to Set Up Audience Signals in Performance Max](/guides/how-to-guides/pmax)
* [Objectives](/getting-started/how-innkeepr-works#objectives)
# Google Ads
Source: https://docs.innkeepr.ai/connections/sources/google-ads
* The Google Ads Connection is an Object Cloud connection. This means that it sends information (traits) about a thing that exists and persists over time, such as a person or company, and which can be updated over time. Data from this connection can only be exported directly to a warehouse, but it can then be used for further analysis.
[Google Ads](https://business.google.com/en-all/google-ads/) is an online advertising service developed by Google. With Google Ads, you can take advantage of online advertising to improve your internet marketing effectiveness.
## Getting Started
1. From your workspace’s page, click **Connections** and then **Browse**.
2. Choose **Google Ads**.
3. Click **Connect** and then Connect to OAuth into Google.
4. Select which accounts you would like to sync.
5. Enter your **Campaign ID**(s).
6. Click **Save**.
## URL Parameters
Innkeepr needs the Google Ads `campaignid` to be passed as a URL parameter so it can correctly match website visits to ad campaigns. You choose the parameter name yourself — just make sure it matches what you entered as **Campaign ID parameter** during the connection setup.
Editing URL parameters on the campaign or ad group level does **not** trigger a new ad review and does **not** affect your optimization score.
Do not use `#` in your naming convention — it causes a cutoff of all following URL parameters.
## Performance Max (PMax)
**Parameters**
Add the following to your tracking template, replacing `your_parameter` with the parameter name you configured in Innkeepr:
`{lpurl}?your_parameter={campaignid}`
If you already have existing URL parameters, append the Innkeepr parameter at the end using `&` instead of `?`:
`{lpurl}?utm_source=google&utm_medium=cpc&your_parameter={campaignid}`
**Implementation**
You can bulk edit all Performance Max campaigns at once:
1. Select "**Performance Max campaigns**" as a workspace filter.
2. Go to **Settings → Campaign settings**.
3. Select all campaigns. If you have multiple pages, click "**Select all xx**" to include everything.
4. Click **Edit → Change tracking templates**.
5. Paste the parameters into the tracking template and click **APPLY**.
Add the **"Tracking template"** column to your PMax campaign settings column preset so you can quickly verify that parameters are applied.
## Shopping & Smart Shopping
**Parameters**
Add the following to your tracking template, replacing `your_parameter` with the parameter name you configured in Innkeepr:
`{lpurl}?your_parameter={campaignid}`
If you already have existing URL parameters, append the Innkeepr parameter at the end:
`{lpurl}?utm_source=google&utm_medium=cpc&your_parameter={campaignid}`
**Implementation**
**For fewer than 100 product groups:**
1. Select "**Shopping campaigns**" as a workspace filter.
2. Go to **Product groups**.
3. Edit your column layout and add the "**Tracking template**" column.
4. Select each product group individually and edit the tracking template.
5. Paste the parameters and click **Save**.
**For more than 100 product groups:**
Use Google Ads' Import/Export feature to bulk edit tracking templates. See [Google's documentation on bulk editing product groups](https://support.google.com/google-ads/answer/6275322).
**Important Notes**
* **Tracking template hierarchy**: If you use tracking templates at multiple levels, the most specific one wins. Priority order: **Ad → Ad Group → Campaign → Account**. Make sure your parameter is not being overridden by a more specific tracking template.
* **Auto-tagging**: Make sure Google Ads auto-tagging is activated.
* **Testing**: You can verify your tracking template by clicking the edit icon on the tracking template and choosing "**Test**". If the URL matches your expected format, tracking will work correctly.
## Permissions
When you set up your Google Ads Connection, you may notice that all the Google Ads accounts your Google user can view aren’t listed. This is because the Google Ads API doesn’t expose a list of “managed” or sub-accounts to non-administrators using the API. That said, if you have read permissions to the account and would like to add it, please contact Support. For more information about finding your Google Ads Customer ID, see Google’s [Find your Google Ads customer ID](https://support.google.com/google-ads/answer/1704344?co=ADWORDS.IsAWNCustomer%3Dfalse\&hl=en) docs.
# Meta
Source: https://docs.innkeepr.ai/connections/sources/meta
* The Meta Ads Connection is an **Audience Signal, Conversion Signal** and **Cloud Object connection**. This means that it sends information (traits) about a thing that exists and persists over time, such as a campaign or ad set, and which can be updated over time. Data from this connection can only be exported directly to a warehouse, but it can then be used for further analysis.
Meta is one of the most efficient ways to advertise online. Take your company’s analysis to the next level by adding [Meta Ads](https://business.facebook.com/latest/ad_center/ads_summary) as a Connection to Innkeepr.
## Getting Started
1. From your workspace’s page, click **Connections** and then **Browse**.
2. Choose **Facebook Ads**.
3. Click **Connect** and then Connect to OAuth into Facebook.
4. Select which accounts you would like to sync.
5. Enter your **Pixel ID**(s). If you have multiple pixels, separate them with a semicolon.
6. Enter your **Ad ID** parameter — this is the URL parameter name you're using to capture `ad.id` in your Meta tracking template.
7. Click **Save**.
## URL Parameter
Innkeepr needs the Meta `ad.id` to be passed as a URL parameter so it can correctly match website visits to individual ads. You choose the parameter name yourself — just make sure it matches what you entered as Ad ID parameter during the connection setup.
Editing URL parameters triggers a new ad review and may restart the learning phase. We recommend making these changes at night or during a less busy time. Do not use `#` in your naming convention — it causes a cutoff of all following URL parameters.
**Parameters**
Add the following to the **URL parameters** field on your Meta ads, replacing `your_parameter` with the parameter name you configured in Innkeepr:
`your_parameter={{ad.id}}`
If you already have existing **URL parameters**, append the Innkeepr parameter at the end using `&`:
`&your_parameter={{ad.id}}`
If you are not using any **URL parameters** yet and want a complete setup including UTMs:
`utm_source=meta&utm_medium=paid&utm_campaign={{campaign.name}}&utm_term={{adset.name}}&utm_content={{ad.name}}&your_parameter={{ad.id}}`
**Implementation**
You can bulk edit up to 200 ads at once using Meta's bulk editing feature:
1. Select all of your campaigns.
2. Navigate to the **ad level**.
3. Select all ads.
4. Press the dropdown next to the "**Edit**" button and choose "**URL parameters**".
5. Add the parameter into the "**Edit all selected ads**" row.
6. Click "**Save to draft**".
7. If you have more than 200 ads, go to the next page and repeat the steps above.
8. Once all ads are edited, publish your changes.
Advantage+ Shopping Campaigns cannot be edited together with regular campaigns. Make sure to edit them separately.
**Best Practices**
* **Messenger Ads**: The "URL parameters" field does not work for Messenger Ads. Filter them out before starting the bulk editing process.
* **Active & recent ads**: If you have a large number of ads, you can filter for active or recently active ads. But make sure you don't leave out any ads that might be turned on or duplicated in the future.
* **Verification**: Add the "**URL parameters**" column to your column preset to quickly check if the correct parameters are applied. Go to **Columns → Customize Columns...** to add it.
* **Preserve engagement**: If you don't want to lose existing engagement on your best-performing ads, consider duplicating the ad with updated parameters instead of editing the original.
## Permissions
To connect Meta Ads as a connection, the Facebook user authenticating the connection needs the following permissions:
**Ad Account Access**
The user needs **Admin** or **Advertiser** role on the Ad Account in Meta Business Manager. This is required to:
* Read campaign, ad set, and ad configurations (including targeting options)
* Upload and manage Custom Audiences
* Modify audience targeting on ad sets
**Pixel Access**
The user needs **Full Access** to each Pixel you want to connect. This allows Innkeepr to send conversion events to your Pixel via the Conversions API.
**How to verify your permissions**
1. Go to [Meta Business Settings → People](https://business.facebook.com/settings/people)
2. Select your user
3. Under **Ad Accounts**, verify you have **Admin** or **Advertiser** access
4. Under **Data Sources → Pixels**, verify you have full access to the relevant Pixel(s)
**Analyst** level access is not sufficient — Innkeepr needs write access to upload audiences and send Pixel events.
# Spec: E-Commerce Events
Source: https://docs.innkeepr.ai/connections/spec-ecommerce
One of the core components of the Innkeepr Spec is the track call. It describes any arbitrary event that the user has triggered. For some industry verticals and applications, Innkeepr has standardized event names. For E-Commerce tracking, for example, there are **specific event names and properties** that we recognize semantically.
This semantic meaning allows Innkeepr to specially recognize and transform key events to build audiences optimized for specific user actions.
## Event lifecycles
Here is a list of supported events for our various categories within the customer journey.
| **ACTION** | **DESCRIPTION** |
| ------------------------ | ----------------------------------------------------------- |
| `search_submitted` | User searched for products |
| `product_added_to_cart` | User added a product to their shopping cart |
| `payment_info_submitted` | User added payment information |
| `checkout_started` | User initiated the order process (a transaction is created) |
| `checkout_completed` | User completed the order |
## Search Submitted
Fire this event when a visitor searches for products.
This event supports the following semantic properties:
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| ------------ | -------- | ---------------------------- |
| `query` | String | Query the user searched with |
Example:
```
Innkeepr.track('search_submitted', {
query: 'blue roses'
});
```
## Product Added to Cart
Fire this event when a visitor adds a product to their shopping cart.
This event supports the following semantic properties:
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| ------------ | -------- | ------------------------------------------------------------------ |
| `cart_id` | String | Cart ID to which the product was added to |
| `product_id` | String | Database id of the product being viewed |
| `sku` | String | SKU of the product being viewed |
| `category` | String | Product category being viewed |
| `name` | String | Name of the product being viewed |
| `brand` | String | Brand associated with the product |
| `variant` | String | Variant of the product |
| `price` | Number | Price (\$) of the product being viewed |
| `currency` | String | Currency code associated with the transaction |
| `quantity` | Number | Quantity of a product |
| `coupon` | String | Coupon code associated with a product (for example, MAY\_DEALS\_3) |
| `url` | String | URL of the product page |
| `image_url` | String | Image url of the product |
Example:
Copy
```
Innkeepr.track('product_added_to_cart', {
cart_id: 'skdjsidjsdkdj29j',
product_id: '507f1f77bcf86cd799439011',
sku: 'G-32',
category: 'Games',
name: 'Monopoly: 3rd Edition',
brand: 'Hasbro',
variant: '200 pieces',
price: 18.99,
currency: 'USD',
quantity: 1,
coupon: 'MAYDEALS',
url: 'https://www.example.com/product/path',
image_url: 'https://www.example.com/product/path.jpg'
});
```
## Payment Info Submitted
Fire this event whenever payment information has been successfully entered.
This event supports the following semantic properties:
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| ----------------- | -------- | ---------------------------------------------- |
| `checkout_id` | String | Checkout transaction ID |
| `order_id` | String | Order ID (optional) |
| `shipping_method` | String | String representing the shipping method chosen |
| `payment_method` | String | String representing the payment method chosen |
Example:
```
Innkeepr.track('payment_info_submitted', {
checkout_id: '507f1f77bcf86cd799439011',
order_id: '50314b8e9bcf000000000000'
});
```
## Checkout Started
Fire this event whenever an order/transaction was started. Fire on the page that the customer lands on after they press the checkout button.
This event supports the following semantic properties:
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| :---------------------- | :------- | :-------------------------------------------------------------------------------------- |
| `order_id` | String | Order/transaction ID |
| `affiliation` | String | Store or affiliation from which this transaction occurred (for example, Google Store) |
| `total` | Number | Revenue (\$) with discounts and coupons added in. |
| `revenue` | Number | Revenue (\$) associated with the transaction (excluding shipping and tax) |
| `shipping` | Number | Shipping cost associated with the transaction |
| `tax` | Number | Total tax associated with the transaction |
| `discount` | Number | Total discount associated with the transaction |
| `coupon` | String | Transaction coupon redeemed with the transaction |
| `currency` | String | [Currency code](https://en.wikipedia.org/wiki/ISO_4217) associated with the transaction |
| `products` | Array | Products in the order |
| `products.$.product_id` | String | Database id of the product being viewed |
| `products.$.sku` | String | SKU of the product being viewed |
| `products.$.category` | String | Product category being viewed |
| `products.$.name` | String | Name of the product being viewed |
| `products.$.brand` | String | Brand associated with the product |
| `products.$.variant` | String | Variant of the product |
| `products.$.price` | Number | Price (\$) of the product being viewed |
| `products.$.currency` | String | [Currency code](https://en.wikipedia.org/wiki/ISO_4217) associated with the transaction |
| `products.$.quantity` | Number | Quantity of a product |
| `products.$.coupon` | String | Coupon code associated with a product (for example, *MAY\_DEALS\_3*) |
| `products.$.url` | String | URL of the product page |
| `products.$.image_url` | String | Image url of the product |
Example:
```
Innkeepr.track('checkout_started', {
order_id: '50314b8e9bcf000000000000',
affiliation: 'Google Store',
total: 30,
revenue: 25.00,
shipping: 3,
tax: 2,
discount: 2.5,
coupon: 'hasbros',
currency: 'USD',
products: [
{
product_id: '507f1f77bcf86cd799439011',
sku: '45790-32',
name: 'Monopoly: 3rd Edition',
price: 19,
currency: 'USD',
quantity: 1,
category: 'Games',
url: 'https://www.example.com/product/path',
image_url: 'https://www.example.com/product/path.jpg'
},
{
product_id: '505bd76785ebb509fc183733',
sku: '46493-32',
name: 'Uno Card Game',
price: 3,
currency: 'USD',
quantity: 2,
category: 'Games'
}
]
});
```
# Checkout Completed
Fire this event whenever a checkout step is completed.
This event supports the following semantic properties:
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| :---------------------- | :------- | :-------------------------------------------------------------------------------------- |
| `checkout_id` | String | Checkout ID |
| `order_id` | String | Order/transaction ID |
| `affiliation` | String | Store or affiliation from which this transaction occurred (for example, Google Store) |
| `subtotal` | Number | Order total after discounts but before taxes and shipping |
| `total` | Number | Revenue (\$) with discounts and coupons added in. |
| `revenue` | Number | Revenue (\$) associated with the transaction (excluding shipping and tax) |
| `shipping` | Number | Shipping cost associated with the transaction |
| `tax` | Number | Total tax associated with the transaction |
| `discount` | Number | Total discount associated with the transaction |
| `coupon` | String | Transaction coupon redeemed with the transaction |
| `currency` | String | [Currency code](https://en.wikipedia.org/wiki/ISO_4217) associated with the transaction |
| `products` | Array | Products in the order |
| `products.$.product_id` | String | Database id of the product being viewed |
| `products.$.sku` | String | SKU of the product being viewed |
| `products.$.category` | String | Product category being viewed |
| `products.$.name` | String | Name of the product being viewed |
| `products.$.brand` | String | Brand associated with the product |
| `products.$.variant` | String | Variant of the product |
| `products.$.price` | Number | Price (\$) of the product being viewed |
| `products.$.currency` | String | [Currency code](https://en.wikipedia.org/wiki/ISO_4217) associated with the transaction |
| `products.$.quantity` | Number | Quantity of a product |
| `products.$.coupon` | String | Coupon code associated with a product (for example, *MAY\_DEALS\_3*) |
| `products.$.url` | String | URL of the product page |
| `products.$.image_url` | String | Image url of the product |
Example:
```
Innkeepr.track('checkout_completed', {
checkout_id: 'fksdjfsdjfisjf9sdfjsd9f',
order_id: '50314b8e9bcf000000000000',
affiliation: 'Google Store',
total: 27.50,
subtotal: 22.50,
revenue: 25.00,
shipping: 3,
tax: 2,
discount: 2.5,
coupon: 'hasbros',
currency: 'USD',
products: [
{
product_id: '507f1f77bcf86cd799439011',
sku: '45790-32',
name: 'Monopoly: 3rd Edition',
price: 19,
currency: 'USD',
quantity: 1,
category: 'Games',
url: 'https://www.example.com/product/path',
image_url: 'https://www.example.com/product/path.jpg'
},
{
product_id: '505bd76785ebb509fc183733',
sku: '46493-32',
name: 'Uno Card Game',
price: 3,
currency: 'USD',
quantity: 2,
category: 'Games'
}
]
});
```
# Spec: Identify
Source: https://docs.innkeepr.ai/connections/spec-identify
The Innkeepr Identify call lets you tie a user to their actions and record **traits** about them. It includes a unique **User ID** and any optional traits you know about the user, like their email, name, and more.
**We recommend that you make an Identify call:**
* After a user first **registers**
* After a user **logs in**
* When a user **updates** their info (for example, they change or add a new address)
* Upon loading any pages that are accessible by a **logged in** user (optional)
The first three examples are pretty self-explanatory, but many might ask: why you would call identify on every page load if we’re storing the userId in the cookie/local storage?
**Let’s imagine this scenario:**
I log into your app. Identify is called. For whatever reason, I close the browser and don’t return until later. There’s no way of knowing where I will reenter your app from. I could start my session from anywhere. And because there are many tools out there that require an initial **identify** call for certain features (e.g. Intercom chat widget) it’s important to tell your end tools who the user is when they first start their session.
Calling identify is one of the first steps to getting started with Innkeepr. Refer to library-specific documentation for more details.
Here’s the payload of a typical identify call:
```
{
"type": "identify",
"traits": {
"name": "Peter Gibbons",
"email": "peter@example.com",
"plan": "premium",
"logins": 5
},
"userId": "97980cfea0067"
}
```
And here’s the corresponding JavaScript event that would generate the above payload:
```
Innkeepr.identify("97980cfea0067", {
name: "Peter Gibbons",
email: "peter@example.com",
plan: "premium",
logins: 5
});
```
Beyond common fields, an identify call has the following fields:
## Identify Call
| **FIELD** | **TEXT** | **TYPE** | **DESCRIPTION** |
| ---------- | -------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **traits** | optional | Object | Free-form dictionary of traits of the user, like email or name. See the [Traits field docs](/connections/spec-identify#traits) for a list of reserved trait names. |
| **userId** | *required; optional if anonymousID is set instead* | String | Unique identifier for the user in your database. A userId or an anonymousId is required. See the [Identities docs](/connections/spec-identify#identities) for more details. |
### Example
Here’s a complete example of an identify call:
```
{
"anonymousId": "507f191e810c19729de860ea",
"context": {
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5)"
},
"messageId": "022bb90c-bbac-11e4-8dfc-aa07a5b093db",
"timestamp": "2015-02-23T22:28:55.111Z",
"traits": {
"name": "Peter Gibbons",
"email": "peter@example.com",
"plan": "premium",
"logins": 5,
"address": {
"street": "6th St",
"city": "San Francisco",
"state": "CA",
"postalCode": "94103",
"country": "USA"
}
},
"type": "identify",
"userId": "97980cfea0067",
"version": "1.1"
}
```
## Identities
The identify call specifies a visitor identity that you can reference across the visitor’s whole lifetime. \*\*Every identify call must have a [User ID](/connections/spec-identify#user-id) or an [Anonymous ID](/connections/spec-identify#anonymous-id), depending on how much you know about the visitor in question.
### Anonymous ID
There are certain cases where you don’t actually know who the visitor is according to your database, but you still want to be able to tie them to **traits**, **events**, or **page views**. For example, you may not know who a user is when tracking newsletter signups or anonymous page views.
In these cases, you should use an **Anonymous ID**.
The Anonymous ID can be any pseudo-unique identifier. For example, on your servers you can use a **session id**. If you don’t have any readily available identifier, you can always generate a new random one - we recommend **UUIDs**.
**Note:** Innkeepr’s libraries **automatically** use Anonymous IDs to keep track of users as they navigate around your website or app, so you don’t need to worry about them when using those libraries.
Here’s an example of a JavaScript event for an anonymous user:
```
Innkeepr.identify({
subscriptionStatus: 'inactive'
});
```
### **User ID**
User IDs are a more permanent and robust **identifier**, like a database ID. Since these IDs are consistent across a customer’s lifetime, identify calls should include a **User ID** as often as possible.
A User ID is usually the unique identifier that you recognize a user by in your own **database**. For example, if you’re using MongoDB it might look something like `507f191e810c19729de860ea`.
We recommend using database IDs instead of simple email addresses or usernames, because database IDs **never change**. That guarantees that even if the user changes their email address, you can still recognize them as the same person in all of your analytics tools. And even better, you’ll be able to correlate analytics data with your own internal database.
**Instead of using an email address or a username as a User ID, send them along as traits.**
### **Traits**
Traits are pieces of information you know about a user that are included in an identify call. These could be demographics like age or gender, account-specific like plan, or even things like whether a user has seen a particular A/B test variation. Up to you!
Innkeepr has reserved some traits that have **semantic meanings** for users, and we handle them in special ways. For example, we always expect email to be a string of the user’s email address. We’ll send this on to destinations like *Klaviyo* that require an email address to build targeting lists.
You should **only use reserved traits for their intended meaning**.
Reserved traits at Innkeepr:
| **TRAIT** | **TYPE** | **DESCRIPTION** |
| -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `address` | Object | Street address of a user optionally containing: city, country, postalCode, state, or street |
| `age` | Number | Age of a user |
| `avatar` | String | URL to an avatar image for the user |
| `birthday` | Date | User’s birthday |
| `company` | Object | Company the user represents, optionally containing: name (String), id (String or Number), industry (String), employee\_count (Number) or plan (String) |
| `createdAt` | Date | Date the user’s account was first created. We recommend using ISO-8601 date strings. |
| `description` | String | Description of the user |
| `email` | String | Email address of a user |
| `email_sha256` | String | The email of a user hashed with SHA256. |
| `firstName` | String | First name of a user |
| `gender` | String | Gender of a user |
| `id` | String | Unique ID in your database for a user |
| `lastName` | String | Last name of a user |
| `name` | String | Full name of a user. If you only pass a first and last name we automatically fill in the full name for you. |
| `phone` | String | Full name of a user. If you only pass a first and last name we automatically fill in the full name for you. |
| `title` | String | Title of a user, usually related to their position at a specific company. Example: “VP of Engineering” |
| `username` | String | User’s username. This should be unique to each user, like the usernames of Twitter or GitHub. |
| `website` | String | Website of a user |
# Spec Overview
Source: https://docs.innkeepr.ai/connections/spec-overview
The Innkeepr Spec provides guidance on meaningful data to capture, and the best format for it, across all of Innkeepr’s libraries and APIs. If you implement Innkeepr using these formats, it’s simple to translate your data to downstream **signals**.
The Innkeepr Spec has three components.
First, it outlines the **semantic definition** of the visitor data Innkeepr captures across all libraries and APIs. There are three **API calls** in the Spec. They each represent a distinct type of semantic information about a visitor. Every call shares the same **common fields**.
APIs
* [Identify](/connections/spec-identify): who is the customer?
* [Track](/connections/spec-track): what are they doing?
* [Page](/connections/spec-page): what web page are they on?
Second, it **details the event data Innkeepr captures across some cloud connections and destinations**.
Cloud Connections and Destinations
* Web
* Email
* Helpdesk
* Live Chat
Third, it shares the **events** Innkeepr recommends you track for a particular industry based on experience working with customers. When you respect these specs, Innkeepr maps these events to particular features within end **destinations** like Google Analytics and Facebook Ads.
Industry Specs
* [E-Commerce](/connections/spec-ecommerce)
* B2B SaaS (Upcoming)
* Mobile (Upcoming)
* Health (Upcoming)
# Spec: Page
Source: https://docs.innkeepr.ai/connections/spec-page
The page call lets you record whenever a user sees a page of your website, along with any optional properties about the page. Calling page or Screen in an Innkeepr connection is one of the first steps to getting started with Innkeepr.
**Note: In innkeepr.js a page call is included in the snippet by default** just after innkeepr.load. Many destinations require this page event to be fired at least once per page load for proper initialization. You may add an optional name or properties to the default call, or call it multiple times per page load if you have a single-page application.
Here’s the payload of a typical page call with most common fields removed:
```
{
"type": "page",
"name": "Home",
"properties": {
"title": "Welcome | Initech",
"url": "http://www.example.com"
}
}
```
And here’s the corresponding JavaScript event that would generate the above payload. If you’re using Innkeepr’s JavaScript library, the page name and URL are automatically gathered and passed as properties into the event payload:
```
Innkeepr.page("Retail page","Home");
```
Beyond the common fields, the page call takes the following fields:
| **FIELD** | **TYPE** | **DESCRIPTION** |
| -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **category** | String | The category of the page, added to the properties object. Passed as the first argument in a page call, for example analytics.page ("category", "name"). |
| **name** | String | Name of the page. For example, most sites have a “Signup” page that can be useful to tag, so you can see users as they move through your funnel. |
| **properties** | Object | Free-form dictionary of properties of the page, like url and referrer. See the Properties field docs for a list of reserved property names. |
## Example
Here’s a complete example of a page call:
```
{
"anonymousId": "507f191e810c19729de860ea",
"channel": "browser",
"context": {
"ip": "8.8.8.8",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36"
},
"integrations": {
"All": true,
"Mixpanel": false,
"Salesforce": false
},
"messageId": "022bb90c-bbac-11e4-8dfc-aa07a5b093db",
"name": "Home",
"properties": {
"title": "Welcome | Initech",
"url": "http://www.example.com"
},
"receivedAt": "2015-02-23T22:28:55.387Z",
"sentAt": "2015-02-23T22:28:55.111Z",
"timestamp": "2015-02-23T22:28:55.111Z",
"type": "page",
"userId": "97980cfea0067",
"version": "1.1"
}
```
## Identities
The User ID is a unique identifier for the user performing the actions. Check out the [User ID docs](/connections/spec-identify#user-id) for more detail.
The Anonymous ID can be any pseudo-unique identifier, for cases where you don’t know who the user is, but you still want to tie them to an event. Check out the [Anonymous ID](/connections/spec-identify#anonymous-id) docs for more detail.
**Note: In our browser and mobile libraries a User ID is automatically added** from the state stored by a previous [identify call](/connections/spec-identify), so you do not need to add it yourself. They will also automatically handle Anonymous IDs under the covers.
## Properties
Properties are extra pieces of information that describe the page. They can be anything you want.
Innkeepr handles properties with semantic meanings in unique ways. For example, Innkeepr always expects path to be a page’s URL path, and referrer to be the previous page’s URL.
You should **only use reserved properties for their intended meaning**.
Reserved properties Innkeepr has standardized:
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| ------------ | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | String | Name of the page. Reserved for future use. |
| `path` | String | Path portion of the page’s URL. Equivalent to canonical path which defaults to location.pathname from the DOM API. |
| `referrer` | String | Previous page’s full URL. Equivalent to document.referrer from the DOM API. |
| `search` | String | Query string portion of the page’s URL. Equivalent to location.search from the DOM API. |
| `title` | String | Page’s title. Equivalent to document.title from the DOM API. |
| `url` | String | Page’s full URL. Innkeepr first looks for the canonical URL. If the canonical URL is not provided, Innkeepr uses location.href from the DOM API. |
| `keywords` | Array\[String] | A list/array of keywords describing the page’s content. The keywords would most likely be the same as, or similar to, the keywords you would find in an HTML meta tag for SEO purposes. Mainly used by content publishers that rely heavily on pageview tracking. Not automatically collected. |
# Spec: Track
Source: https://docs.innkeepr.ai/connections/spec-track
The track API call is how you record any actions your users perform, along with any properties that describe the action.
Each action is known as an event. Each event has a name, like **User Registered**, and properties. For example, a **User Registered** event might have properties like plan or accountType. Calling track in one of our connections is one of the first steps to getting started with Innkeepr.
Here’s the payload of a typical track call with most common fields removed:
```
{
"type": "track",
"event": "User Registered",
"properties": {
"plan": "Pro Annual",
"accountType" : "Facebook"
}
}
```
And here’s the corresponding JavaScript event that would generate the above payload:
```
Innkeepr.track("User Registered", {
plan: "Pro Annual",
accountType: "Facebook"
});
```
Beyond the common fields, the track call has the following fields:
| **FIELD** | | **TYPE** | **DESCRIPTION** |
| ---------- | ---------- | -------- | ----------------------------------------------------------------------------------------------------------------------------- |
| event | *required* | String | Name of the action that a user has performed. See the Event field docs for more details. |
| properties | *optional* | Object | Free-form dictionary of properties of the event, like revenue. See the Properties docs for a list of reserved property names. |
**Example**
Here’s a complete example of a track call:
```
{
"anonymousId": "636908973e90a7aca7d309fb",
"context": {
"library": {
"name": "innkeepr.js",
"version": "1.0"
},
"page": {
"path": "/academy/",
"referrer": "",
"search": "",
"title": "Analytics Academy",
"url": "https://innkeepr.ai/docs"
},
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36"
},
"event": "Course Clicked",
"messageId": "ajs-f8ca1e4de5024d9430b3928bd8ac6b96",
"properties": {
"title": "Intro to Analytics"
},
"timestamp": "2015-12-12T19:11:01.249Z",
"type": "track",
"userId": "AiUGstSDIg"
}
```
### **Identities**
The [User ID](/connections/spec-identify#user-id) is a unique identifier for the user performing the actions. Check out the User ID docs for more detail.
The [Anonymous ID](/connections/spec-identify#anonymous-id) can be any pseudo-unique identifier, for cases where you don’t know who the user is, but you still want to tie them to an event. Check out the Anonymous ID docs for more detail.
**Note: In our browser and mobile libraries a User ID is automatically added** from the state stored by a previous identify call, so you do not need to add it yourself. They will also automatically handle Anonymous IDs under the covers.
### **Event names**
Every track call records a single user action. We call these “events”, and recommend that you make your event names human-readable, so that everyone on your team (even you, after all that caffeine) can know what they mean instantly.
Don’t use nondescript names like **Event 12** or **TMDropd**. Instead, use unique but recognizable names like **Video Recorded** and **Order Completed**.
Innkeepr has standardized a series of reserved event names that have special semantic meaning. We map these events to tools that support them whenever possible. See the Semantic Events docs for more detail.
### **Properties**
Properties are extra pieces of information you can tie to events you track. They can be anything that will be useful while analyzing the events later. We recommend sending properties whenever possible because they give you a more complete picture of what your users are doing.
Innkeepr has reserved some properties that have semantic meanings, and handle them in special ways. For example, we always expect revenue to be a euro amount that we send to tools that handle revenue tracking.
You should **only use reserved properties for their intended meaning**.
The following are all of the reserved properties Innkeepr has standardized that apply to all events. Check out the Semantic Events docs for properties specific to individual reserved events.
| **PROPERTY** | **TYPE** | **DESCRIPTION** |
| ------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **revenue** | Number | Amount of revenue an event resulted in. This should be a decimal value, so a shirt worth €19.99 would result in a revenue of 19.99. |
| **currency** | String | Currency of the revenue an event resulted in. This should be sent in the [ISO 4217 format](http://en.wikipedia.org/wiki/ISO_4217). If this isn’t set, Innkeepr assumes the revenue to be in euros. |
| **value** | Number | An abstract “value” to associate with an event. Typically used in situations where the event doesn’t generate real-dollar revenue, but has intrinsic value to a marketing team, like newsletter signups. |
# A Basic Installation
Source: https://docs.innkeepr.ai/getting-started/a-basic-installation
This guide walks you through the complete Innkeepr setup. Follow these steps to enable audience signals and conversion signals for your engagement stack.
## Overview
A complete installation includes four steps:
1. **Install Innkeepr.js** – Add the tracking script to your site
2. **Track Conversions** – Capture purchase events with revenue data
3. **Identify Users** – Connect user emails for advanced audience features
4. **Connect Platforms** – Link your ad accounts and analytics
**Timeline:** Most installations are completed within 60 minutes.
## Step 1: Install Innkeepr.js
Innkeepr.js automatically captures page views and provides methods for tracking conversions and identifying users.
Set up a **JavaScript** connection under **Connections** in the Innkeepr app to get your tracking snippet.
**Install via Tag Manager (Recommended)**
1. Open Google Tag Manager (or your preferred tag manager)
2. Create a new **Custom HTML** tag
3. Paste the Innkeepr.js snippet
4. Set the trigger to **All Pages**
5. Save and publish
**Install Directly (Alternative)**
Paste the snippet into the `` section of your website, before other scripts.
**Verify Installation**
Once installed, open your website and check the Event Debugger in the Innkeepr app:
1. Navigate to **Events**
2. You should see `page` events appearing in real-time
Learn More
* [Connections Overview](/connections/overview)
* [Innkeepr Spec](/connections/spec-overview)
* [Testing and Debugging](/getting-started/testing-and-debugging)
## Step 2: Track Conversions
Conversion tracking is essential for enabling audience and conversion signals. The track method captures key user actions along with their properties.
**Basic Conversion Tracking**
Fire a `track` call when a user completes a purchase or other conversion event:
```java javascript theme={null}
Innkeepr.track('Order Completed', {
revenue: 99.95,
order_id: 'ORD-12345',
currency: 'EUR'
});
```
**Required Properties**
| Property | Type | Description |
| :-------- | :----- | :-------------------------------------------- |
| `revenue` | Number | Order value (required for Conversion Signals) |
**Recommended Properties**
| Property | Type | Description |
| :--------- | :----- | :--------------------------------- |
| `order_id` | String | Unique order identifier |
| `currency` | String | ISO currency code (EUR, USD, etc.) |
| `products` | Array | List of purchased products |
**Tag Manager Implementation**
1. Create a new **Custom HTML** tag in Google Tag Manager
2. Add the track call with dynamic variables from your data layer:
```java html theme={null}
Innkeepr.track('Order Completed', {
revenue: {{DL - Order Total}},
order_id: {{DL - Order ID}},
currency: {{DL - Currency}}
});
```
3. Set the trigger to fire on your purchase confirmation page or transaction event
**Important:** The `revenue` property is required for Conversion Signals. Without it, incrementality-weighted conversion values cannot be calculated.
**Additional Events**
Track other meaningful user actions to improve audience quality:
```java javascript theme={null}
// Product viewed
Innkeepr.track('Product Viewed', {
product_id: 'SKU-789',
category: 'Shoes',
price: 129.00
});
// Added to cart
Innkeepr.track('Product Added', {
product_id: 'SKU-789',
quantity: 1,
price: 129.00
});
```
**Note:** Some connections (e.g., Shopify) automatically implement track calls for standard e-commerce events. Check the Connections Catalog before implementing manually.
Learn More
* [Spec: Track](/connections/spec-track)
* [Standard Events](/connections/overview)
* [Connections Catalog](/connections/sources/google-ads)
## Step 3: Identify Users
The `identify` method connects user actions to known identities. This enables Value-Based Audiences on Meta and improves cross-device tracking.
**Basic User Identification**
Fire an identify call when a user completes a purchase or logs in:
```java javascript theme={null}
Innkeepr.identify('user_12345', {
email: 'customer@example.com'
});
```
**Required Traits for Value-Based Audiences**
| Trait | Type | Description |
| :------ | :----- | :------------------------------- |
| `email` | String | User's email address (plaintext) |
**Or:**
| Trait | Type | Description |
| :------------- | :----- | :----------------------------------------------- |
| `email_sha256` | String | SHA256-hashed email address (lowercase, trimmed) |
**Tag Manager Implementation**
1. Create a new **Custom HTML** tag in Google Tag Manager
2. Add the identify call with variables from your data layer:
```java html theme={null}
Innkeepr.identify('user_12345', {
email: 'customer@example.com'
});
```
**Or with hashed email:**
```java html theme={null}
Innkeepr.identify({{DL - User ID}}, {
email_sha256: {{DL - Customer Email SHA256}}
});
```
3. Set the trigger to fire on purchase confirmation (same as your conversion tracking trigger)
**Additional Traits**
Include additional traits to enrich user profiles:
```java javascript theme={null}
Innkeepr.identify('user_12345', {
email: 'customer@example.com',
name: 'Maria Schmidt',
created_at: '2024-01-15',
lifetime_value: 450.00,
customer_type: 'returning'
});
```
**Important:** The `email` or `email_sha256` trait is required for Value-Based Audiences on Meta and Custom Audiences on TikTok. Without it, audience matching relies solely on pixel-based identification.
Learn More
* [Spec: Identify](/connections/spec-identify)
## Step 4: Connect Platforms
Connect your advertising platforms and analytics to enable audience syncing and conversion signals.
**Required Connections**
Navigate to **Connections > Add Connection** and connect the following:
| Platform | Purpose |
| :----------------- | :---------------------------------------------------------- |
| Google Analytics 4 | Audience sync via GA4 audiences |
| Google Ads | Audience signals, Conversion signals |
| Meta Ads | Audience signals, Conversion signals, Value-Based Audiences |
Each platform has its own connection setup (authentication, account selection, tracking parameters) — follow the connection-specific guide for the exact steps.
**Note:** Connect all ad accounts where you plan to use Innkeepr audiences or conversion signals.
Learn More
* [Google Analytics 4](/connections/sources/ga4)
* [Google Ads](/connections/sources/google-ads)
* [Meta](/connections/sources/meta)
## Next Steps
Once your installation is validated, you're ready to create your first signals:
1. **Create an Objective** – Define the business outcome your signals optimize for
2. **Create Signals** – Build audience or conversion signals for that objective
Learn More
* [Signals Overview](/concepts/signals)
# Getting Started Guide
Source: https://docs.innkeepr.ai/getting-started/getting-started-guide
Welcome to Innkeepr. This guide helps you understand what Innkeepr does, how it works, and what steps to take to get your first signals live.
## What is Innkeepr?
Innkeepr is a marketing analytics platform that uses causal inference to measure the true incremental impact of your advertising. Instead of relying on attribution models that count conversions regardless of whether ads caused them, Innkeepr predicts which users will convert because of your ads-and optimizes your campaigns accordingly.
**The result:** Audience signals that target truly incremental users, and conversion signals that train platform algorithms toward real business impact.
## How Innkeepr Works
Innkeepr operates in four stages:
1. **Collect Data** Innkeepr.js captures behavioral data from your website—page views, product interactions, conversions, and user identities. Platform connections bring in campaign exposure data from Google, Meta, and other channels.
2. **Train Models** Causal models analyze which users were exposed to which campaigns and what outcomes they achieved. The models estimate individual treatment effects: the predicted incremental impact of showing an ad to a specific user.
3. **Generate Signals** Treatment effect scores become actionable signals—audience segments ranked by predicted incrementality, and conversion values weighted by causal contribution.
4. **Optimize Platforms** Signals sync directly to your ad platforms. Audiences guide targeting toward high-incrementality users. Conversion signals train bidding algorithms to prioritize truly incremental conversions.
Learn More
* [Signals Overview](/concepts/signals)
## Your First Steps
Complete these tasks to get Innkeepr up and running:
Decide who needs access to Innkeepr-typically marketing leads, performance managers, and developers responsible for implementation.
1. Go to **Settings > Workspace Settings > User Management**
2. Click **+ Invite Team Member**
3. Enter email addresses separated by commas
4. Click **Invite**
Follow the Installation Guide to set up tracking and connect your platforms. The installation covers:
* Innkeepr.js installation via Tag Manager
* Conversion tracking with revenue data
* User identification with email
* Platform connections (GA4, Google Ads, Meta Ads)
**Timeline:** Most installations are completed within 1-2 hours.
Learn More
* [Installation Guide](/getting-started/a-basic-installation)
After installation, verify that data is flowing correctly:
1. Navigate to **Events** in the Innkeepr app
2. Confirm `page` events appear from website visits
3. Confirm conversion events appear with `revenue` property
4. Confirm `identify` calls appear with `email` trait
Learn More
* [Testing and Debugging](/getting-started/testing-and-debugging)
Once data is flowing, create your first audience signal:
1. Go to **Audiences**
2. Click **Create**
3. Enter a name
4. Select the destination platform (Google Ads, Meta Ads)
5. Choose your conversion goal
6. Select the audience type (Seed, Retargeting, or Exclusion)
7. Click **Create**
Innkeepr will notify you when the audience is populated and ready to use in your ad platform.
Learn More
* [Audience Signals](/concepts/audience-signals)
* [How to Set Up Audience Signals on Meta](/guides/how-to-guides/meta)
* [How to Set Up Audience Signals in Performance Max](/guides/how-to-guides/pmax)
Stream incrementality-weighted conversion values to your ad platforms:
1. Go to **Signals**
2. Click **Create**
3. Enter a name
4. Choose the conversion event to adjust (must include revenue)
5. Select the destination platform
6. Click **Create**
Learn More
* [Conversion Signals](/concepts/conversion-signals)
## What You Can Achieve
Innkeepr enables four primary use cases:
**Acquisition – Better Lookalikes**
Seed audiences contain users with the highest predicted incremental response. Platforms use these seeds to find similar prospects, improving acquisition efficiency compared to traditional lookalikes based on converters.
**Retargeting – Incremental Re-engagement**
Retargeting audiences identify users who interacted with your brand but haven't converted, and who are predicted to respond incrementally to additional touchpoints. Reach users who need the nudge, not users who would convert anyway.
**Spend Protection – Smart Exclusions**
Exclusion audiences identify users with low or negative incrementality-people who would convert without ad exposure or who are unlikely to respond regardless. Exclude them to reduce wasted spend and ad fatigue.
**Bidding – Incrementality-Weighted Conversions**
Conversion signals adjust the values sent to platform bidding algorithms. High-incrementality conversions pass full value; low-incrementality conversions pass reduced value. This trains algorithms to prioritize users and placements that deliver true causal impact.
## What to Expect
Here's a typical timeline from installation to live signals:
| Timeframe | Milestone |
| :-------- | :--------------------------------------------- |
| Day 1 | Installation complete, data flowing |
| Day 2-3 | Initial events validated in Event Debugger |
| Week 1-2 | Sufficient data for first model training |
| Week 2-4 | Models training, predictions stabilizing |
| Week 4+ | First audiences populated, ready for campaigns |
**Note:** Signal quality improves over time. Early implementations may have wider confidence intervals. After 2-3 model training cycles (4-6 weeks), predictions stabilize and signal performance improves measurably.
## Help & Support
**Documentation** Browse the helpdesk for detailed guides on specific topics-platform setup, troubleshooting, best practices.
**Contact** Reach out to your Innkeepr contact or [support@innkeepr.com](mailto:support@innkeepr.com) for implementation questions or technical issues.
## Next Steps
Ready to dive deeper? Explore these guides:
Learn More
* [Installation Guide](/getting-started/a-basic-installation)
* [Signals Overview](/concepts/signals)
* [Audience Signals](/concepts/audience-signals)
* [Conversion Signals](/concepts/conversion-signals)
* [How to Set Up Audience Signals on Meta](/guides/how-to-guides/meta)
* [How to Set Up Audience Signals in Performance Max](/guides/how-to-guides/pmax)
# How Innkeepr works
Source: https://docs.innkeepr.ai/getting-started/how-innkeepr-works
Innkeepr is the signal optimization platform that makes your marketing stack incrementality-aware. Our causal analytics engine sits between your customer data and engagement tools - transforming behavioral data into audience and conversion signals optimized for incremental impact on your business metrics.
## Overview
![Innkeepr Logo]()
Innkeepr operates as data infrastructure for your marketing stack. We process interaction data from websites, apps, and backend systems to identify cause-and-effect relationships between touchpoints and business outcomes. These insights become **incrementality-optimized signals that flow directly into Google, Meta, TikTok, Amazon, and other platforms**.
**Two components activate Innkeepr:**
**Event collection:** Connect your data sources using Innkeepr's tracking libraries or server-side APIs. Send events like `checkout_completed`, `signup`, or `product_viewed` with relevant attributes (`order_value`, `is_new_customer`, `source`).
**Objective definition:** Define what matters to your business - CLV, purchase probability, AOV, retention - and Innkeepr optimizes signals for those outcomes.
Once configured, Innkeepr analyzes daily traffic to detect which touchpoints drive incremental impact on your objectives. These predictions become signals that sync automatically to connected platforms, making your entire marketing stack optimize for causation, not correlation.
# Common use cases
Marketing and growth teams use Innkeepr's signal layer to:
* Seed lookalikes with high-incrementality users for new customer acquisition
* Weight conversion values by incremental contribution
* Target segments by predicted CLV impact
* Suppress spend on low-AOV or non-incremental traffic
* Build exclusion audiences that protect budget
## Collecting data
Innkeepr provides tracking infrastructure through two connection types:
[**Innkeepr.js**](/getting-started/getting-started-guide#install-innkeepr-js) – Client-side tracking for web properties. Captures behavioral data as users navigate your site.
**Server-side connections** – Backend tracking for mission-critical events like revenue or when client-side isn't feasible.
## The Innkeepr tracking spec
Our tracking libraries follow a standardized message structure that feeds Innkeepr's causal engine. Three core methods capture user context:
* [**Identify**](/connections/spec-identify) – Who is the user?
* [**Page**](/connections/spec-page) – What are they viewing?
* [**Track**](/connections/spec-track) – What action are they taking?
Consistent implementation ensures clean signal generation. These events flow into our causal analytics engine and become activation-ready signals for downstream platforms.
## How Innkeepr builds incrementality signals
Signals are how Innkeepr makes platform algorithms incrementality-aware. The system processes two inputs: **objectives** (the business outcomes you're optimizing for) and
**treatments** (the marketing touchpoints users encountered). Together, these power our causal engine.
## Objectives
Objectives define what success means for your business—CLV, purchase probability, order value, retention. They can come from tracked events (`checkout_completed` with `revenue`) or calculated user traits (`is_new_customer`, `revenue_30d`).
You can define multiple objectives and version them independently. Segment by additional traits like *CLV for new customers in EU* or *7-day retention from paid social* to optimize different growth surfaces.
## Signals
### Audience signals
Predictive segments built on forecasted incremental value. Instead of targeting by demographics or past behavior, Innkeepr identifies users most likely to deliver lift against your objective. These segments sync directly into platform audience targeting (Meta Custom Audiences, Google Customer Match) so algorithms focus on high-incrementality users.
### Conversion signals
Conversion values weighted by incremental contribution. Rather than passing raw transaction amounts, Innkeepr adjusts each conversion based on its predicted lift over baseline. Platform bidding algorithms receive signals aligned with actual causal impact—not just correlation with sales.
### Treatment effects
Innkeepr's signals are powered by continuous analysis of treatment effects - the incremental impact of specific marketing touchpoints on your objectives.
**Treatments** in Innkeepr correspond to ad sets, ad groups, or asset groups across Google, Meta, and other platforms. Our attribution system matches each session to the treatment that drove it using a 7-day first-touch attribution model, allowing us to determine which touchpoints caused each visit and how users behaved afterward.
**Treatment effects** quantify incremental impact. For example: *This Meta ad set drove a +€12 lift in CLV compared to baseline.* Innkeepr learns these effects from historical data and continuously refines predictions as new data flows in.
This feedback loop keeps models aligned with current behavior and market conditions. Over time, signal accuracy improves—meaning connected platforms optimize bidding and targeting based on the most current causal insights available.
# Testing and Debugging
Source: https://docs.innkeepr.ai/getting-started/testing-and-debugging
**Event Debugger**
The Event Debugger is a real-time validation tool for confirming that tracking calls from your connections reach your Innkeepr workspace. Use it to verify your implementation and troubleshoot data flow **before signals reach your causal engine**.
The Debugger shows a **live sample of events** as they arrive at Innkeepr's API - up to **50 events at a time**. This is separate from your **signal processing pipeline** and provides immediate feedback on whether your **tracking implementation** is structured correctly.
Use the Debugger to
Use the Debugger to:
\- **validate event firing**
\- **confirm payload structure**
\- ensure data reaches your workspace **before it’s transformed into signals**
The Debugger displays incoming events **in real time**. Toggle between `Live` and `Pause` to stop the stream from updating while you inspect payloads. Events continue arriving to your connection while paused - you're just controlling the display.
Search for specific payloads using any field in the event's raw data. Use **advanced filters** to narrow results to **specific event types**, making it easier to validate **particular tracking implementations**.
The Raw view shows the complete **JSON object** Innkeepr received from your tracking call. This includes:
\- **timestamps**
\- **properties**
\- **traits**
\- **user IDs**
\- **contextual data**
Use this view to verify that your events **match Innkeepr’s tracking spec** before they’re processed by the causal engine and transformed into **audience and conversion signals**.
# Choosing a Use Case
Source: https://docs.innkeepr.ai/getting-started/use-cases/choosing-a-use-case
Use Cases provide implementation blueprints for configuring Innkeepr's **signal optimization** around specific **business objectives**. This guide helps you select the use case that aligns with your **growth goals** and determines how signals flow from your data to your marketing platforms.
## Understanding business goals and signal strategies
Innkeepr supports use cases organized into 4 core **business objectives**:
* Improve **new customer acquisition**
* Suppress spend on **unlikely converters**
* Boost **retention**, **upsell**, and **cross-sell**
* Increase **long-term profitability**
Each objective requires different **signal types**, **tracking events**, and **platform configurations**. Use cases define these requirements so your signal optimization infrastructure drives the outcomes you need.
## Selecting your use case
Follow these steps to identify which use case to implement:
from the four business goals above
evaluating which signal strategy aligns with your specific needs
and what additional events you'll need to collect
and which destinations require audience vs. conversion signals
if you're uncertain—you can expand to additional use cases over time
Your use case selection determines which events to track, how objectives are defined, and which signal types activate in your platforms. Innkeepr's **modular architecture** allows you to add use cases as your signal optimization strategy evolves.
The following sections detail each business goal and its associated **signal strategies**.
## Improve new customer acquisition
This goal centers on growing your customer base by reaching **high-probability new customers**. By processing your behavioral data through Innkeepr's **causal engine**, you generate audience signals that identify users most likely to deliver **incremental acquisition lift**—enabling platform algorithms to find similar high-value prospects.
**Key considerations:**
* Need to lower **customer acquisition costs**?
* Want to expand reach into new **high-value segments**?
* Looking to drive **app installations** or **signups**?
* Trying to reduce **cart abandonment** among new users?
**Use cases in this category:**
| Use Case | Signal | Strategy |
| :------------------------------------------------------ | :----------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Build seeds based on predicted ad impact** | Audience signals | Generate seed audiences from users with high predicted responsiveness to campaigns—creating larger, higher-quality seeds even with limited conversion data |
| **Exclude recent purchasers or converters** | Audience signals, Exclusions | Suppress users with recent conversions to reduce overlap and improve seed purity for prospecting campaigns |
| **Tune conversion values based on predicted ad impact** | Conversions signals | Weight conversion values by incremental contribution so platform bidding algorithms optimize for true acquisition impact |
| **Predict signup likelihoods to grow user base** | Audience signals | Process behavioral signals (session depth, engagement) to model signup intent and generate predictive seed audiences |
| **Identify high-value customers** | Audience signals, Exclusions, Conversion signals | Build seeds from high-LTV or low-churn segments for lookalike modeling focused on quality acquisition |
## Suppress spend on unlikely converters
This goal improves efficiency by excluding users with **low predicted conversion probability** before budget is spent. Exclusion signals reduce wasted impressions, focus spend on **high-quality traffic**, and lower **CAC** by refining early-funnel targeting.
**Key considerations:**
* Seeing high **click volume** but low **conversion rates**?
* Want to avoid paying for **low-intent traffic**?
* Looking to improve **CAC** through better audience filtering?
**Use cases in this category:**
| Use Case | Strategy |
| :--------------------------------------------- | :----------------------------------------------------------------------------------------------------------------- |
| **Exclude low LTV visitors** | Identify visitors with low predicted monetization potential and suppress them from retargeting before spend occurs |
| **Pre-qualify traffic before retargeting** | Filter based on session quality or engagement signals to limit retargeting to high-intent visitors only |
| **Suppress low-propensity app installs** | Exclude users with low predicted install likelihood based on behavioral or contextual signals |
| **Filter cart abandoners unlikely to convert** | Segment cart abandoners by recovery probability and suppress those unlikely to complete purchase |
| **Suppress low signup intent** | Remove users with weak behavioral indicators from signup-focused campaigns |
| **Suppress churn-prone free users** | Prevent remarketing to users showing early churn signals during onboarding or trial periods |
## Boost retention, upsell, and cross-sell
This goal maximizes value from existing customers by optimizing signals for repeat purchase, product expansion, and long-term engagement. Signals generated for this objective help platforms identify which customers are most likely to respond to retention or expansion offers.
**Key considerations for this goal:**
* Want to increase **purchase frequency** from existing customers?
* Need to prevent **churn** among high-value segments?
* Looking to personalize **upsell** or **cross-sell** targeting?
* Want to find new customers who resemble your **best repeat buyers**?
**Use cases in this category:**
| Use Case | Strategy |
| :---------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Target customers with next-best offer** | Process purchase history and product affinity to identify cross-sell or upsell opportunities and generate signals for personalized follow-up campaigns |
| **Accelerate first purchase** | Optimize signals for users in early journey stages to drive faster time-to-first-purchase |
| **Promote first-time offers** | Generate audience signals for new users most likely to respond to incentives (discounts, free shipping) |
| **Convert browsers to buyers** | Identify high-intent product viewers and create signals that prioritize them in retargeting campaigns |
| **Recover abandoned carts** | Detect and signal users who abandoned carts with high recovery probability for urgency-based messaging |
# Use Case Overview
Source: https://docs.innkeepr.ai/getting-started/use-cases/overview
Use Cases are pre-built Innkeepr setup guides tailored to common **business goals**.
Use cases eliminate guesswork with a structured approach to **onboarding**, helping you configure Innkeepr correctly and align its features to your **business objectives**.
You can onboard to Innkeepr with a use case if you’re a **new customer** or haven’t yet connected a **connection** and **destination**.
## Onboard to Innkeepr with Use Cases
Not sure where to start? Read through Innkeepr's Choosing a use case guide, which breaks down the available business goals and their associated use cases.
Looking for something more technical? View the use cases Reference, which lists the tracking events, connections, and destinations Innkeepr recommends for each use case.
## Take the next step
Collect event data from your mobile apps, websites, and servers.
Build, enrich, and activate audiences with Innkeepr's audience engine.
Track user interactions, resolve their identities, and explore Profiles.
Stream impact-adjusted conversion signals to your media platforms.
# Use Cases Reference
Source: https://docs.innkeepr.ai/getting-started/use-cases/use-case-references
This reference guide provides technical specifications for each Innkeepr use case, including
required **tracking events**, **objective definitions**, **signal types**, and **destination configurations**. Use this guide to validate your implementation and ensure your signal optimization infrastructure is
configured correctly for your **business objective**.
## Use Cases by business goal
Your business goal determines which signal strategies and use cases Innkeepr configures
during setup.
This table maps each business goal to its corresponding use cases:
| Business Goal | Use Cases |
| :------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Improve new customer
acquisition** | Build seeds based on predicted ad impact
Exclude recent purchasers or converters
Tune conversion values based on predicted ad impact
Predict signup likelihoods to grow user base
Identify high-value customers |
| **Suppress spend on
unlikely converters** | Exclude low-LTV visitors
Pre-qualify traffic before retargeting
Suppress low-propensity app installs
Filter cart abandoners unlikely to convert
Suppress low signup intent
Suppress churn-prone free users |
| **Boost retention, upsell,
and cross-sell** | Target customers with next-best offer
Accelerate first purchase
Promote first-time offers
Convert browsers to buyers
Recover abandoned carts |
| **Increase long-term
profitability** | Optimize for customer lifetime value
Weight conversions by incremental margin
Suppress low-AOV traffic
Target high-retention segments |
## Use case specifications
Each use case section below details the required configuration for signal generation:
* **Required events:** Tracking calls needed to power the causal engine
* **Objective definition:** How to configure the business metric Innkeepr optimizes for
* **Signal types:** Which audience and conversion signals are generated
* **Destinations:** Platform connections where signals activate
* **Expected data requirements:** Minimum conversion volume and traffic thresholds
## Improve new customer acquisition
These use cases generate signals optimized for growing your customer base with high-quality,
incremental new customers.
**Objective:** Identify users most likely to deliver incremental response to ad campaigns and use
them as seed audiences for lookalike expansion.
**Required events:**
* page - Track page views with `url`, `path`, `referrer`
* track: `product_viewed` - Include `product_id`, `category`, `price`
* track: `checkout_started` - Include `cart_value`, `product_ids`
* track: `order_completed` - Include `order_value`, `order_id`, `is_new_customer`
* identify - Include `user_id`, `anonymous_id`
**Objective configuration:**
* **Primary metric:** Purchase probability or conversion rate
* **Segmentation:** Filter by `is_new_customer`: true
* **Lookback window:** 7-30 days
**Signal types generated:**
* **Audience signals:** High-incrementality seed audiences (top 10-20% predicted responders)
* Syncs as Custom Audiences (Meta), Customer Match (Google), Custom Audiences
(TikTok)
**Destinations:**
* Google Ads (Customer Match)
* Meta Ads (Custom Audiences)
* TikTok Ads (Custom Audiences)
* Amazon Ads (Audience segments)
**Minimum requirements:**
* 500+ conversions per month
* 10,000+ monthly sessions
* At least one connected media platform with conversion tracking
**Objective:** Suppress users who recently converted to improve seed purity and reduce wasted
prospecting spend.
**Required events:**
* track: `order_completed` - Include `order_id`, `order_value`, `timestamp`
* identify - Include `user_id`, `email`, `phone` (for platform matching)
**Objective configuration:**
* **Exclusion window:** 7-90 days (configurable)
* **Event trigger:** `order_completed` or custom conversion event
* **Refresh frequency:** Daily
**Signal types generated:**
* **Exclusion signals:** Audiences of recent converters
* Syncs as exclusion lists to prospecting campaigns
**Destinations:**
* Google Ads (exclusion lists)
* Meta Ads (exclusion audiences)
* TikTok Ads (exclusion audiences)
**Minimum requirements:**
* 100+ conversions per month
* Email or phone tracking enabled for platform matching
**Objective:** Weight conversion values by incremental contribution so bidding algorithms optimize
for true causal impact.
**Required events:**
* track: `order_completed` - Include `order_value`, `order_id`, `user_id`
* page - Include UTM parameters, `referrer`, `landing_page`
* identify - Include `user_id`, `anonymous_id`
**Objective configuration:**
* **Primary metric:** Revenue or order value
* **Attribution:** First-touch, 7-day window
* **Value adjustment:** Multiplier based on treatment effect (0.5x - 2.0x typical range)
**Signal types generated:**
* **Conversion signals:** Incrementality-weighted conversion values
* Replaces standard conversion events with adjusted values
* Real-time sync on each conversion
**Destinations:**
* Google Ads (conversion value adjustments)
* Meta Ads (conversion value optimization)
* TikTok Ads (value-based optimization)
**Minimum requirements:**
* 300+ conversions per month
* Revenue tracking implemented
* UTM parameters or referrer tracking enabled
**Objective:** Model signup intent from behavioral signals to generate predictive seed audiences
for user acquisition.
**Required events:**
* page - Include `url`, `path`, `time_on_page`
* track: `form_started` - Include `form_type`, `timestamp`
* track: `signup_completed` - Include `user_id`, `signup_method`
* Session-level traits: `page_depth`, `session_duration`, `source`
**Objective configuration:**
* **Primary metric:** Signup probability
* **Features:** Session depth, engagement time, page sequence, referrer
* **Model type:** Logistic regression or gradient boosting
**Signal types generated:**
* **Audience signals:** High-signup-propensity users (top 15-25%)
* Updates daily based on recent behavioral patterns
**Destinations:**
* Google Ads (Customer Match for signup campaigns)
* Meta Ads (signup-focused audiences)
* TikTok Ads (signup campaigns)
**Minimum requirements:**
* 200+ signups per month
* Session tracking implemented
* At least 5,000 monthly anonymous sessions
**Objective:** Build seed audiences from high-LTV or low-churn customer segments for
quality-focused acquisition.
**Required events:**
* track: `order_completed` - Include `order_value`, `order_id`, `user_id`
* identify - Include `user_id`, `lifetime_value`, `order_count`
* Calculated traits: `ltv_90d`, p`urchase_frequency`, `avg_order_value`
**Objective configuration:**
* **Primary metric:** Customer lifetime value (CLV) or predicted LTV
* **Segmentation:** Top 20-30% by LTV or retention probability
* **Refresh:** Weekly or as LTV calculations update
**Signal types generated:**
* **Audience signals:** High-LTV customer seeds
* **Exclusion signals:** Low-LTV or high-churn segments (optional)
* **Conversion signals:** LTV-weighted conversion values (optional)
**Destinations:**
* Google Ads (Value-based lookalikes)
* Meta Ads (Value-based Custom Audiences)
* TikTok Ads (High-value lookalikes)
**Minimum requirements:**
* 500+ customers with repeat purchase data
* LTV calculation or lifetime revenue tracking
* 90+ day historical data
## Suppress spend on unlikely converters
These use cases generate exclusion signals that prevent wasted spend on low-incrementality
traffic.
**Objective:** Identify and suppress visitors with low predicted monetization potential before
retargeting budget is spent.
**Required events:**
* page - Include `url`, `referrer`, `session_id`
* track: `product_viewed` - Include `product_id`, `price`, `category`
* identify - Include `user_id`, `anonymous_id`
* Session traits: `traffic_source`, `device_type`, `geo`
**Objective configuration:**
* **Primary metric:** Predicted LTV or purchase probability
* **Exclusion threshold:** Bottom 20-40% of predicted LTV distribution
* **Refresh frequency:** Daily
**Signal types generated:**
* **Exclusion signals:** Low-LTV visitor segments
* Syncs as exclusion audiences to retargeting campaigns
**Destinations:**
* Google Ads (exclusion lists for remarketing)
* Meta Ads (exclusion audiences)
* Criteo (exclusion segments)
**Minimum requirements:**
* 1,000+ monthly sessions
* Product view or engagement tracking
* At least 200 conversions for model training
**Objective:** Filter retargeting audiences based on session quality signals to focus spend on
high-intent visitors.
**Required events:**
* page - Include `time_on_page`, `bounce`, `session_depth`
* track: `product_viewed` - Include `view_count`, `time_spent`
* Session-level traits: `pages_per_session`, `session_duration`, `scroll_depth`
**Objective configuration:**
* **Qualification criteria:** Minimum session depth (2+ pages), time on site (30+ seconds),
or engagement events
* **Exclusion logic:** Suppress sessions below quality thresholds
* **Refresh:** Real-time or daily
**Signal types generated:**
* **Exclusion signals:** Low-quality session audiences
* **Audience signals:** High-intent qualified visitors (optional)
**Destinations:**
* Google Ads (remarketing exclusions)
* Meta Ads (retargeting exclusions)
* TikTok Ads (retargeting filters)
**Minimum requirements:**
* 5,000+ monthly sessions
* Session depth and time tracking enabled
**Objective:** Exclude users with low predicted install likelihood from app install campaigns.
**Required events:**
* track: `app_install` - Include `install_source`, `user_id`
* page (app landing page) - Include `referrer`, `device_type`, `os`
* Pre-install engagement: track: `video_played`, track: `cta_clicked`
**Objective configuration:**
* **Primary metric:** App install probability
* **Features:** Device type, OS, referrer, landing page engagement
* **Exclusion threshold:** Bottom 30-50% predicted probability
**Signal types generated:**
* **Exclusion signals:** Low-install-propensity users
* **Audience signals:** High-propensity install audiences (optional)
**Destinations:**
* Google Ads (app install campaigns)
* Meta Ads (app install exclusions)
* TikTok Ads (app install campaigns)
**Minimum requirements:**
* 200+ app installs per month
* App event tracking implemented
* Landing page or pre-install engagement data
**Objective:** Segment cart abandoners by recovery probability and suppress those unlikely to
complete purchase.
**Required events:**
* track: `checkout_started` - Include `cart_value`, `product_ids`, `timestamp`
* track: `order_completed` - Include `order_id`, `order_value`
* Session context: `time_in_checkout`, `payment_method_added`
**Objective configuration:**
* **Primary metric:** Cart recovery probability
* **Features:** Cart value, time spent in checkout, product category, abandonment count
* **Exclusion threshold:** Bottom 40-60% recovery probability
**Signal types generated:**
* **Exclusion signals:** Low-recovery cart abandoners
* **Audience signals:** High-recovery abandoners for prioritized retargeting (optional)
**Destinations:**
* Google Ads (cart abandonment exclusions)
* Meta Ads (dynamic retargeting exclusions)
* Klaviyo (email suppression lists)
**Minimum requirements:**
* 300+ cart abandonment events per month
* Order completion tracking
* 30+ day historical abandonment data
**Objective:** Remove users with weak behavioral indicators from signup-focused campaigns.
**Required events:**
* page (signup page) - Include `time_on_page`, `bounce`
* track: `form_started` - Include `form_type`, `abandonment`
* track: `signup_completed` - Include `signup_method`
* Session traits: `referrer`, `landing_page`, `session_depth`
**Objective configuration:**
* **Primary metric:** Signup probability
* **Exclusion criteria:** Low engagement (quick bounce, no form interaction)
* **Threshold:** Bottom 30-50% predicted signup likelihood
**Signal types generated:**
* **Exclusion signals:** Low-signup-intent visitors
* Updates in real-time or daily batches
**Destinations:**
* Google Ads (signup campaign exclusions)
* Meta Ads (lead gen exclusions)
* TikTok Ads (signup campaign filters)
**Minimum requirements:**
* 200+ signups per month
* Form tracking and signup page analytics
* 5,000+ monthly sessions
**Objective:** Prevent remarketing to users showing early churn signals during onboarding or trial periods.
**Required events:**
* track: `trial_started` - Include `user_id`, `trial_type`, `timestamp`
* track: `feature_used` - Include `feature_name`, `usage_count`
* identify - Include user engagement traits: `days_active`, `feature_adoption`
* track: `trial_ended` or track: `subscription_cancelled`
**Objective configuration:**
* **Primary metric:** Churn probability during trial or onboarding
* **Features:** Feature adoption, days active, engagement frequency
* **Exclusion threshold:** Top 30-50% churn risk
**Signal types generated:**
* **Exclusion signals:** High-churn-risk trial users
* Prevents upsell or paid conversion spend on likely churners
**Destinations:**
* Google Ads (trial conversion exclusions)
* Meta Ads (subscription campaign exclusions)
* Email platforms (suppression lists)
**Minimum requirements:**
* 100+ trial starts per month
* Feature usage tracking
* Trial outcome data (conversion or churn)
## Boost retention, upsell, and cross-sell
These use cases optimize signals for maximizing value from existing customers through repeat
purchases and product expansion.
**Objective:** Use purchase history and product affinity to identify cross-sell or upsell opportunities and generate personalized targeting signals.
**Required events:**
* track: `order_completed` - Include `product_ids`, `categories`, `order_value`
* track: `product_viewed` - Include `product_id`, `category`, `timestamp`
* identify - Include purchase history traits: `last_purchase_date`, `favorite_category`, `total_orders`
**Objective configuration:**
* **Primary metric:** Product affinity score or next purchase probability
* **Recommendation logic:** Complementary products, bundle opportunities, category expansion
* **Refresh:** Weekly or after each purchase event
**Signal types generated:**
* **Audience signals:** Product-specific cross-sell or upsell audiences
* Segmented by next-best-offer category or product
**Destinations:**
* Google Ads (cross-sell campaigns)
* Meta Ads (dynamic product audiences)
* Email platforms (personalized recommendations)
**Minimum requirements:**
* 500+ customers with purchase history
* Product catalog with categories or SKU relationships
* Multiple product categories or SKUs
**Objective:** Optimize signals for users in early journey stages to drive faster
time-to-first-purchase.
**Required events:**
* page - Include landing page, session sequence
* track: `product_viewed` - Include view count, time spent
* track: `cart_added` - Include `product_id`, `timestamp`
* track: `order_completed` - Include `days_to_purchase`, `is_new_customer`
**Objective configuration:**
* **Primary metric:** Time to first purchase or purchase probability
* **Segmentation:** New visitors or users without prior purchases
* **Optimization:** Shortest time-to-conversion predictions
**Signal types generated:**
* **Audience signals:** High-first-purchase-propensity new visitors
* **Conversion signals:** Weighted by speed to first conversion (optional)
**Destinations:**
* Google Ads (new customer acquisition)
* Meta Ads (first-purchase campaigns)
* TikTok Ads (conversion campaigns)
**Minimum requirements:**
* 300+ first-time purchases per month
* New vs. returning customer tracking
* Session and product view data
**Objective:** Generate audience signals for new users most likely to respond to incentive offers like discounts or free shipping.
**Required events:**
* page - Include `landing_page`, `referrer`, `session_id`
* track: `coupon_viewed` or track: `offer_displayed`
* track: `order_completed` - Include `coupon_used`, `discount_amount`, `is_new_customer`
* identify - Include `is_new_customer`, `first_visit_date`
**Objective configuration:**
* **Primary metric:** Offer response probability or discount sensitivity
* **Segmentation:** New users only (first 1-7 days)
* **Model type:** Propensity to convert with incentive
**Signal types generated:**
* **Audience signals:** Incentive-responsive new users
* Prioritized for first-purchase discount campaigns
**Destinations:**
* Google Ads (promotion campaigns)
* Meta Ads (offer-based acquisition)
* Email platforms (welcome discount flows)
**Minimum requirements:**
* 200+ new customer conversions per month
* Discount or coupon tracking
* New vs. returning segmentation
**Objective:** Identify high-intent product viewers and create signals that prioritize them in
retargeting campaigns.
**Required events:**
* track: `product_viewed` - Include `product_id`, `price`, `time_spent`
* track: `cart_added` - Include `product_id` (optional, for intent scoring)
* track: `order_completed` - Include `product_ids`, `order_value`
* Session traits: `view_count`, `category_views`, `price_range_viewed`
**Objective configuration:**
* **Primary metric:** Purchase probability for product viewers
* **Features:** View frequency, time on product page, price range, category depth
* **Threshold:** Top 20-40% purchase probability
**Signal types generated:**
* **Audience signals:** High-intent browser segments
* Can be product-specific or category-specific
**Destinations:**
* Google Ads (dynamic remarketing)
* Meta Ads (dynamic product ads)
* Criteo (product retargeting)
**Minimum requirements:**
* 1,000+ product views per month
* 200+ conversions per month
* Product catalog connected
**Objective:** Detect and signal users who abandoned carts with high recovery probability for
urgency-based messaging.
**Required events:**
* track: `checkout_started` - Include `cart_value`, `product_ids`, `timestamp`
* track: `order_completed` - Include `order_id`, `order_value`
* identify - Include `email`, `phone`, `user_id` (for matching)
* Session context: `abandonment_reason` (if tracked), `payment_method_added`
**Objective configuration:**
* **Primary metric:** Cart recovery probability
* **Features:** Cart value, abandonment timing, product type, prior abandonment behavior
* **Segmentation:** High-recovery probability (top 30-50%)
**Signal types generated:**
* **Audience signals:** High-recovery abandoners for prioritized retargeting
* **Exclusion signals:** Low-recovery abandoners to suppress spend (optional)
**Destinations:**
* Google Ads (cart recovery campaigns)
* Meta Ads (dynamic cart retargeting)
* Klaviyo (abandoned cart emails)
**Minimum requirements:**
* 300+ cart abandonment events per month
* Email or user ID tracking for matching
* Order completion tracking
## Increase long-term profitability
These use cases optimize signals for sustainable, profitable growth focused on customer
lifetime value and margin contribution.
**Objective:** Generate signals weighted by predicted CLV to guide platforms toward customers
who deliver the most long-term value.
**Required events:**
* track: `order_completed` - Include `order_value`, `product_ids`, `user_id`
* identify - Include calculated traits: `lifetime_value`, `order_count`, `avg_order_value`, `days_since_first_purchase`
* track: `subscription_started` or recurring revenue events (if applicable)
**Objective configuration:**
* **Primary metric:** 90-day or 180-day predicted CLV
* **Model inputs:** Purchase frequency, AOV, recency, product mix, cohort behavior
* **Refresh:** Weekly or as new transaction data arrives
**Signal types generated:**
* **Audience signals:** High-CLV prospect segments (for lookalikes)
* **Conversion signals:** CLV-weighted conversion values for bidding optimization
**Destinations:**
* Google Ads (value-based bidding)
* Meta Ads (value optimization)
* TikTok Ads (value-based campaigns)
**Minimum requirements:**
* 500+ customers with repeat purchase data
* 90+ days of transaction history
* Repeat purchase rate >20%
**Objective:** Adjust conversion values based on product margin contribution so bidding
algorithms optimize for profitability, not just revenue.
**Required events:**
* track: `order_completed` - Include `order_value`, `product_ids`, `order_id`
* Product catalog with margin data: `product_id`, `cost`, `margin_percentage`
* identify - Include `user_id`
**Objective configuration:**
* **Primary metric:** Contribution margin or profit per order
* **Value calculation:** (Revenue - COGS) weighted by incremental effect
* **Sync frequency:** Real-time on each conversion
**Signal types generated:**
* **Conversion signals:** Margin-weighted conversion values
* Replaces revenue-based conversion values with profit-based values
**Destinations:**
* Google Ads (profit-optimized bidding)
* Meta Ads (margin-based optimization)
* Amazon Ads (profitability signals)
**Minimum requirements:**
* 300+ conversions per month
* Product margin data available
* Multiple products with varying margins
**Objective:** Exclude users predicted to generate low average order values to focus budget on
higher-value transactions.
**Required events:**
* track: `order_completed` - Include `order_value`, `user_id`
* track: `product_viewed` - Include `price`, `category`
* Session traits: `price_range_viewed`, `product_count_viewed`
**Objective configuration:**
* **Primary metric:** Predicted AOV
* **Exclusion threshold:** Bottom 20-40% of AOV distribution
* **Refresh:** Daily or weekly
**Signal types generated:**
* **Exclusion signals:** Low-AOV visitor segments
* Suppresses from prospecting or retargeting
**Destinations:**
* Google Ads (AOV-focused exclusions)
* Meta Ads (value campaign exclusions)
* TikTok Ads (exclusion audiences)
**Minimum requirements:**
* 300+ conversions per month
* Wide AOV distribution (3x+ range between high and low)
* Price or product view tracking
**Objective:** Build audience signals around users with high predicted retention or repeat
purchase probability.
**Required events:**
* track: `order_completed` - Include `order_id`, `user_id`, `timestamp`
* identify - Include retention traits: `days_since_last_purchase`, `order_count`, `purchase_frequency`
* track: `subscription_renewed` (if applicable)
**Objective configuration:**
* **Primary metric:** Repeat purchase probability or retention likelihood
* **Model type:** Survival analysis or repeat purchase propensity
* **Segmentation:** Top 20-30% retention probability
**Signal types generated:**
* **Audience signals:** High-retention customer seeds for lookalikes
* **Exclusion signals:** Low-retention or one-time buyer suppression (optional)
**Destinations:**
* Google Ads (retention-focused lookalikes)
* Meta Ads (high-LTV audiences)
* Email platforms (loyalty campaigns)
**Minimum requirements:**
* 500+ customers with purchase history
* 20%+ repeat purchase rate
* 90+ days of transaction data
## Implementation support
For detailed implementation guidance on any use case, refer to:
* [Innkeepr tracking specification for event structure and properties](/connections/spec-track)
* Objective configuration guide for defining business metrics
* [Destination setup guides for platform-specific signal activation](/concepts/signals)
* Signal quality monitoring for validating signal performance
# What is Innkeepr
Source: https://docs.innkeepr.ai/getting-started/what-is-innkeepr
Innkeepr is the **signal optimization platform** that sits between your customer data and marketing stack - transforming interaction data into **incrementality-optimized signals** for Google, Meta, TikTok, Amazon, and other platforms.
We process behavioral data from websites, apps, and backend systems through **causal AI** to generate audience and conversion signals that reflect **incremental impact** on your most relevant business metrics.
**How it works**
Track user interactions across your digital properties using Innkeepr's client-side and server-side libraries. This data flows into our **causal engine**, which identifies what drives incremental growth and transforms those insights into activation-ready signals. These signals sync automatically to your connected platforms - no manual uploads, no CSV exports.
**Two signal types power your stack**
identify high-value segments based on predicted incremental contribution, enabling platforms to reach users most likely to deliver lift.
weight each conversion by its incremental effect, training bidding algorithms to optimize for actual business impact rather than baseline behavior.
**The result**: Platform algorithms receive the data foundation they need to optimize for what actually drives **growth** - **automatically**, **continuously**, and **without guesswork**.
# How to Set Up Audience Signals on Criteo
Source: https://docs.innkeepr.ai/guides/how-to-guides/criteo-audiences
## Overview
Innkeepr connects your first-party data to **Criteo** to power dynamic retargeting and predictive acquisition campaigns.
Through incremental prediction models, Criteo can target high-value users, exclude recent converters, and optimize dynamic creatives based on real user intent and product data.
Unlike Meta or TikTok, Criteo combines **audience signals** with **product feed optimization**.
This means that user segments from Innkeepr (e.g. high-value shoppers, churn risks) are matched with your live merchant feed to deliver relevant product ads across web and app inventory.
***
## Prerequisites
**Technical Requirements:**
* Active **Criteo Advertiser Account**
* Active **Product Feed** (XML, CSV, or Merchant Center sync)
* **Criteo OneTag** installed on your website (or Events API)
* Innkeepr integration connected to your Criteo account
***
## Use Cases
Innkeepr supports four primary use cases for **Criteo audience signals**:
### 1. Seed Audiences – Prospecting
Use high-quality seed segments (e.g. top 30% predicted converters) to power Criteo’s **Similar Audience** expansion.
Best for: Cold acquisition campaigns that target new users similar to your best customers.
### 2. Retargeting Audiences – Re-engagement
Retarget users who viewed products or started checkout but didn’t complete a purchase.
Innkeepr ensures only users with incremental conversion potential are included.
Best for: Dynamic retargeting ads that feature recently viewed or abandoned products.
### 3. Exclusion Audiences – Spend Protection
Exclude users who recently purchased or are predicted to have low incremental impact.
Best for: Preventing ad waste on converted or inactive users.
### 4. Value-Based Audiences – CLV Segmentation
Create segments based on lifetime value (LTV), purchase frequency, or subscription tier.
Best for: Tiered campaigns that prioritize premium or high-value customers.
***
## Setup Instructions
### Step 1: Connect Criteo to Innkeepr
1. In **Innkeepr**, navigate to **Connections → Browse**
2. Click **Connect Criteo**
3. Sign in with your Criteo Advertiser credentials
4. Grant Innkeepr permissions to:
* Upload audience lists
* Send event data (view, add\_to\_cart, purchase)
* Access merchant feed attributes
5. Confirm the connection — Criteo will now appear as an active destination
***
### Step 2: Create Audiences in Innkeepr
1. In **Innkeepr → Audiences**, click **Create Audience**
2. Choose **Criteo** as your destination
3. Set **Audience Type** to:
* *Seed* for prospecting
* *Retargeting* for re-engagement
* *Exclusion* to remove users from campaigns
4. Define segmentation rules (e.g. 30-day lookback, top 50% incremental score)
5. Set your campaign **objective** (e.g. conversion, retention)
6. Click **Create** — your audience will sync to Criteo within 24–48 hours
***
## Monitor & Optimize
Test Innkeepr audiences against your existing Criteo setup before rolling them out broadly. Keep creatives, bidding, and budget identical between control and test so performance differences are attributable to the Innkeepr audience.
**Weeks 1–2: Observation Phase**
* Do **not** adjust budgets, bids, or creatives during the initial learning phase
* Confirm both the control and test campaigns are spending their allocated budget
* Verify that conversions are being tracked correctly
**Weeks 2–4: Evaluation**
* Compare **ROAS, new customer share, and AOV** between the control and test campaigns
* For exclusion audiences, watch that reduced reach does not cut conversion volume without improving efficiency
* For seed and retargeting audiences, check whether the Innkeepr segment outperforms your standard Criteo audiences
**After Week 4: Rollout**
* Roll the best-performing audiences out to your other active Criteo campaigns
* Scale budget on winning audiences incrementally (20–30% per increase) and allow 3–5 days to stabilize before evaluating again
* Refresh audiences periodically so predictions stay current
***
## Best Practices
* **Segmentation depth:** Keep audiences large enough for delivery (1,000+ users recommended)
* **Creative isolation:** Test one variable at a time — if you add or change creatives, do so across control and test simultaneously
* **Dynamic creatives:** Enable Criteo's Dynamic Ads format so audience segments are paired with personalized product recommendations
* **Value tiers:** Use Innkeepr's LTV scoring to run tiered bid strategies (e.g. Gold, Silver, Bronze)
* **Feed hygiene:** Keep your product feed refreshed and free of expired or unavailable products so ads render correctly
* **Combine audience types:** Seed, retargeting, and exclusion audiences are complementary — apply exclusions to prospecting and retargeting campaigns once each audience has been validated individually
***
## Troubleshooting
### Audience Not Populating
**Issue:** Audiences don’t appear in Criteo
**Solutions:**
* Confirm Criteo is connected as a destination in Innkeepr
* Ensure your OneTag or API events are firing (`view_item`, `add_to_cart`, `purchase`)
* Check minimum audience size (1,000 users recommended)
* Wait 24–48 hours for sync
***
### Feed Sync Failed
**Issue:** Product feed not updating or missing items
**Solutions:**
* Verify your feed URL or upload schedule in Criteo Merchant Center
* Ensure feed attributes match required fields (ID, price, URL)
* Check that product IDs align with event IDs in Innkeepr
***
### Low Match Rate
**Issue:** Audience size in Criteo much smaller than in Innkeepr
**Solutions:**
* Confirm emails or hashed identifiers are included in Innkeepr audiences
* Check for missing product IDs in event payloads
* Allow 24–48 hours for data matching to complete
***
### Purchase Events Missing
**Issue:** Criteo doesn’t receive purchase data
**Solutions:**
* Verify `purchase` events are firing correctly on the confirmation page
* Confirm your Criteo pixel or API is active and authorized
* Review Innkeepr → Events for incoming purchase events
* Contact Innkeepr support if issue persists
***
## Related Articles
* [Set Up Seed Audiences on TikTok](/guides/how-to-guides/tiktok-seeds)
* [Set Up Seed Audiences on Meta](/guides/how-to-guides/meta-seeds)
* [Set Up Audience Signals on Performance Max](/guides/how-to-guides/pmax-audiences)
* [Conversion Signals](/concepts/conversion-signals)
* [Spec: Identify](/connections/spec-identify)
# Set Up Conversion Signals on Google Ads
Source: https://docs.innkeepr.ai/guides/how-to-guides/google-conversions
## Overview
Innkeepr Conversion Signals are modified conversion events sent to Google Ads in place of standard conversion data. Depending on the optimization type, Innkeepr adjusts either the number of conversions (count-based) or the value of each conversion (value-based). Both types are adjusted based on the historic incremental contribution of each touchpoint.
Google's bidding algorithm processes these adjusted signals the same way it processes standard conversion data. No changes to campaign structure or bidding strategy type are required.
This guide covers the setup of Innkeepr Conversion Signals on Google Ads campaigns.
## Prerequisites
**Technical Requirements:**
* Active Google Ads account
* **Enhanced Conversions** enabled in your Google Ads account
* **Enhanced Conversions for Leads** enabled in your Google Ads account
* Email address passed to Innkeepr for each user session — this is required for matching conversion events to users. Email handoff works via one of two methods:
* Shop system integration (e.g. Shopify) — email is captured automatically at checkout
* [Innkeepr Identify](/connections/spec-identify) — for custom implementations where you pass the email via the Identify call
> **Both Enhanced Conversions and Enhanced Conversions for Leads must be active in Google Ads.** Without these, Google cannot match Innkeepr's adjusted conversion values back to individual users. See [Google's documentation](https://support.google.com/google-ads/answer/11062876) for setup instructions.
**Timeline at a Glance:**
| Phase | Duration | What Happens |
| ------------------------- | ----------------------------- | ------------------------------------------------ |
| Signal setup | Manual setup by Innkeepr team | Conversion signals configured for your account |
| Campaign learning phase | 30–60 days | Google's bidding adapts to new conversion values |
| Performance stabilization | 60–90 days | Reliable data for evaluation |
> **Important:** Do not evaluate performance before the 60-day mark. Google's bidding algorithm needs time to recalibrate based on the new conversion values. Early results are unreliable.
## How Conversion Signals Work
Innkeepr provides two types of conversion signals, depending on whether the campaign's bidding strategy optimizes for conversion count or conversion value.
**Count-Based Conversion Signals**
Used with bidding strategies that optimize for conversion count (e.g. Maximize Conversions, Target CPA).
Innkeepr modifies the number of conversions that Google Ads receives. Conversions with low predicted incremental impact are withheld — Google does not see them. Conversely, for sessions where the model predicts high incremental impact but no conversion was recorded, Innkeepr generates a synthetic conversion event. The result is a conversion count that reflects incremental volume rather than total volume.
**Value-Based Conversion Signals**
Used with bidding strategies that optimize for conversion value (e.g. Maximize Conversion Value, Target ROAS).
Innkeepr adjusts the reported value of each conversion event. A conversion where the ad had high incremental impact retains most of its original value. A conversion where the user would likely have purchased anyway receives a reduced value. The total number of conversions stays the same — only the values change.
In both cases, Google's bidding algorithm processes the signals the same way it processes standard conversion data. No changes to campaign structure or bidding strategy type are required.
## Setup Instructions
**Step 1: Verify Prerequisites**
Before requesting signal setup, confirm the following:
* **Enhanced Conversions** is enabled in Google Ads (Settings → Conversions → Enhanced Conversions)
* **Enhanced Conversions for Leads** is enabled in Google Ads
* **Email address** is being passed to Innkeepr for each user session via shop system integration or [Innkeepr Identify](/connections/spec-identify)
* Sufficient conversion history is available (minimum 30 days recommended)
**Step 2: Request Signal Setup**
Conversion signal setup is currently configured manually by the Innkeepr team. To start the process:
**Send an email to [product@innkeepr.ai](mailto:product@innkeepr.ai)** with your Google Ads account ID (MCC or individual account).
Our team will configure the conversion signals for your account and confirm once the setup is complete.
**Step 3: Set Up A/B Testing via Google Experiments**
To measure the impact of conversion signals, use **Google Ads Experiments** to create a controlled test:
1. **Navigate to Experiments** in your Google Ads account (Campaigns → Experiments)
2. **Create a new experiment** based on the campaign that will receive conversion signals
3. **Set the traffic split** — we recommend a 20–30% test / 70–80% control split
4. **Apply the conversion signal** only to the experiment variant (the Innkeepr team will coordinate this with you)
5. **Set the experiment duration** to a minimum of 60 days
Google Experiments handles traffic splitting and statistical significance calculations automatically, which makes it the preferred method for testing conversion signals compared to manual campaign splits.
**Step 4: Adjust Bidding Targets**
After conversion signals are applied, the data Google Ads receives changes — either in conversion count (count-based) or conversion value (value-based). This affects how the bidding algorithm evaluates performance, and bidding targets may need to be adjusted.
**For value-based signals (Target ROAS):**
The total reported conversion value will typically be lower than with standard tracking, because values now reflect incremental contribution. If the tROAS stays the same as the control, Google may restrict bidding because the target becomes harder to reach with lower reported values.
**For count-based signals (Target CPA):**
The total number of reported conversions will change — some conversions are withheld, others are added synthetically. If the tCPA stays the same as the control, Google may over- or underspend depending on the net change in conversion count.
How to approach this:
1. Start the experiment with the **same bidding targets** (tROAS or tCPA) as the control
2. After **7–14 days**, check whether the experiment variant is receiving sufficient budget
3. If the experiment variant underspends, **reduce tROAS by 5–10%** or **increase tCPA by 5–10%** and wait another 7–14 days
4. Repeat until the experiment variant spends its allocated budget consistently
> **Example (value-based):** With standard tracking, a €100 order reports €100 in conversion value. With Innkeepr conversion signals, that same order might report €60 if the model estimates 60% incremental contribution. The same tROAS target becomes harder to reach with lower reported values, so Google reduces spend.
## Monitor & Optimize
**Weeks 1–2: Spend Verification**
* Monitor that the experiment variant is **receiving sufficient spend** — if delivery is too low, reduce tROAS by 5–10% and wait another 7–14 days (see Step 4)
* Verify that conversion signals are being recorded correctly in Google Ads
**Weeks 2–4: Early Evaluation**
* If the experiment variant is still underspending, continue reducing tROAS in 5–10% increments
* If the experiment variant is overspending relative to the control, increase tROAS slightly
* Allow **7–14 days** after any adjustment before re-evaluating
**Weeks 4–12: Performance Review**
* Aim for **50–100+ conversions** in both experiment and control before drawing conclusions
* Google Experiments will report statistical significance — wait until the experiment reaches at least 90% confidence before making decisions
* Compare **actual revenue** from your attribution system, backend, or GA4 (not Google-reported conversion value) between experiment and control to assess true performance impact
> **Key distinction:** The reported conversion values in Google Ads will look different between experiment and control because the conversion signals adjust the values. Always compare on actual revenue from your attribution system, backend, or GA4 — not on Google-reported ROAS.
## Best Practices
**Comparing Experiment vs. Control**
Because conversion signals change the reported data in Google Ads, you cannot directly compare Google-reported metrics between the experiment and control. Use data from your attribution system, backend, or GA4 instead.
Compare relevant metrics depending on your objective and business model, such as ROAS, new customer ratio / CAC, AOV, or CPA.
**tROAS Calibration**
Finding the right tROAS for the experiment variant is an iterative process:
* Start with the same tROAS as the control campaign
* Check spend allocation after 7–14 days
* If the experiment underspends, reduce tROAS by 5–10% and wait another 7–14 days
* Repeat until the experiment spends consistently
## Troubleshooting
**Experiment Variant Not Spending**
| Possible Cause | Solution |
| ---------------------------------- | ----------------------------------------------------------------------------------- |
| tROAS too high for adjusted values | Reduce tROAS by 5–10% and wait 7–14 days — repeat until spend stabilizes |
| Enhanced Conversions not active | Verify Enhanced Conversions and Enhanced Conversions for Leads are both enabled |
| Email matching issues | Confirm email addresses are being passed correctly via shop integration or Identify |
**Conversion Values Look Unexpectedly Low**
This is expected behavior. Innkeepr conversion signals adjust values based on incremental impact — the reported conversion value in Google Ads reflects the incremental contribution, not the full order revenue. Compare on actual backend revenue instead.
**No Conversions Recorded**
| Possible Cause | Solution |
| ----------------------------------- | ------------------------------------------------------------------------------------- |
| Email not being passed | Verify integration via shop system or [Innkeepr Identify](/connections/spec-identify) |
| Enhanced Conversions not configured | Check Google Ads Settings → Conversions → Enhanced Conversions |
| Signal setup incomplete | Contact [product@innkeepr.ai](mailto:product@innkeepr.ai) to verify configuration |
Learn more
* [Audience Signals](/concepts/audience-signals)
* [Set Up Audience Signals on PMax](/guides/how-to-guides/pmax)
* [Set Up Seed Audiences on Meta](/guides/how-to-guides/meta)
* [Spec: Identify](/connections/spec-identify)
# Set Up Exclusion Audiences on Meta
Source: https://docs.innkeepr.ai/guides/how-to-guides/meta-exclusions
## Overview
Exclusion Signals identify users with low or negative predicted incrementality. These users either do not convert at all or convert regardless of ad exposure — in both cases, excluding them from campaigns prevents spend on users where advertising has no measurable effect.
This guide covers the setup of Exclusion Signals on Meta, including configuration, testing, and scaling.
## Prerequisites
**Technical requirements:**
* An active connection to your Meta Ads account
* Sufficient data history for signal generation (30 days minimum recommended)
**Timeline at a glance:**
| Phase | Duration | What happens |
| -------------- | --------------- | -------------------------------------------------------- |
| Matching phase | 24–48 hours | Meta matches the uploaded users and populates the signal |
| Testing phase | 2–4 weeks | Performance comparison against broad targeting |
| Scaling phase | After 2–4 weeks | Budget reallocation based on results |
## How Exclusion Signals Work
Innkeepr ranks anonymous visitors by predicted incremental lift for the objective you select — conversion probability, customer lifetime value, or average order value. Visitors at the bottom of that ranking show low or negative treatment effects: advertising has no measurable impact on whether they reach the objective.
What sets this apart from traditional customer exclusions is where the ranking starts. Innkeepr scores visitors on the anonymous level — **no login, no email, and no CRM match required**. Behavioral first-party signals are enough to identify someone as non-incremental long before they identify themselves, which is where the vast majority of paid traffic sits. The same logic extends to identified customers: a visitor who has already fired a purchase event may be very likely to buy again, but that likelihood is often organic rather than ad-driven. Anonymous non-incremental traffic and existing customers end up in the same place — excluded — for the same reason: the ad does not change the outcome.
## Setup Instructions
**Step 1: Create Exclusion Signals**
Exclusion Signals are built from different user segments, each with its own lookback window. The segments identify groups of users where ad exposure is unlikely to have an incremental impact.
There are different ways to configure Exclusion Signals, and not every setup works equally well across all accounts. The optimal configuration depends on factors such as conversion volume, product category, and overlap with your existing audiences.
As of March 2026, we recommend the following segments as a starting point.
**Recommended segments:**
Start with three visitor segments at different lookback windows, plus one purchaser segment. Splitting visitors across multiple lookback windows lets you see which recency band drives the most incremental value and adjust each one independently.
| Segment | Lookback window | Description |
| ----------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Visitors (recent) | 30 days | Recent site visitors with low predicted incremental lift — they are already aware of your brand and unlikely to be influenced by additional ad exposure |
| Visitors (mid) | 30–90 days | Visitors from the last one to three months — brand awareness is still relatively fresh, and additional ad exposure is unlikely to change their behavior |
| Visitors (older) | 90–180 days | Visitors from three to six months ago — included to capture longer consideration cycles while still excluding users where ads have little measurable effect |
| Purchasers | 360 days (adjust to your new-customer definition) | Users who purchased within the last year — they have already converted and are unlikely to deliver incremental value from acquisition campaigns. Set the lookback window to match how your business defines a new customer (for example, a shorter window if repeat purchases within the year are still worth re-acquiring) |
Each segment is created in Innkeepr and uploaded to Meta. After the first upload, Innkeepr sends `innkeepr_targeting` events to your connected Meta pixel. You need to approve these events in **Meta Events Manager** before Meta processes the signal data. Without this approval, Exclusion Signals will not populate.
**Step 2: Set Up the Campaign Structure**
Test Exclusion Signals within a single campaign using separate ad sets. Both the control and the test ad set use the same base targeting and your existing default exclusions. The test ad set adds the Exclusion Signals on top.
**Campaign structure:**
| Ad set | Targeting | Exclusions | Purpose |
| ------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| Control | Broad targeting | Your default exclusions | Baseline performance |
| Test | Broad targeting (same as control) | Your default exclusions + Innkeepr Exclusion Signals (Visitors 30d, Visitors 30–90d, Visitors 90–180d, Purchasers 360d) | Measures the impact of the Exclusion Signals |
**Important:** Keep all other variables identical across ad sets:
* The same **creatives** (images, videos, copy) in every ad set
* The same **optimization event** (e.g. Purchase, Add to Cart)
* The same **bid strategy**
* The same **placements** (or all set to Advantage+)
* The same **base targeting** — the only difference is the added Exclusion Signals
**Step 3: Set Budget Allocation**
Start both ad sets with the **same daily budget** using **ad set budget optimization (ABO)**. Do not use campaign budget optimization (CBO / Advantage Campaign Budget) during the test phase — CBO shifts spend unpredictably between ad sets, which makes it difficult to compare performance.
After one to two weeks, you can begin adjusting budgets based on observed performance (see Monitor & Optimize).
## Monitor & Optimize
**Weeks 1–2: Observation phase**
* Do **not** adjust budgets, bids, or creatives during the initial learning phase
* Check that both ad sets are **spending their allocated budget** and exiting the learning phase
* Verify that conversions are tracked correctly across both ad sets
**Weeks 2–4: Evaluation**
* Compare **ROAS, new customer share, and AOV** between the control and the test ad set
* The impact of Exclusion Signals depends on the objective and the business model. Exclusion Signals can improve ROAS by removing low-incrementality spend, but they can also shift the new customer ratio — for example, excluding past purchasers concentrates budget on acquisition
* If the test ad set reduces conversion volume significantly without improving any of these metrics, the exclusion segments may be too broad — consider adjusting the lookback windows
**After week 4: Rollout**
Once you have identified the best-performing exclusion segments:
* **Apply the Exclusion Signals** to your other active campaigns on Meta
* **Combine multiple segments** — you can apply all exclusion segments to the same ad set simultaneously
* **Monitor performance** after rollout — allow one to two weeks for each campaign to stabilize
* Exclusion Signals can be combined with Seed Signals in the same campaign — apply seed-based LALs as targeting and Exclusion Signals as exclusions on the same ad sets
## Best Practices
**Creative isolation**
The test is only valid if the creatives are identical across all ad sets. If you want to test new creatives or add additional creatives during the test, add them to all ad sets at the same time. Never add creatives to only some ad sets — this makes performance differences between ad sets unattributable.
**Combining with Seed Signals**
Exclusion Signals and Seed Signals serve complementary purposes: Seed Signals direct spend toward high-incrementality users, while Exclusion Signals remove low-incrementality users from the targeting pool. Using both at the same time is the recommended configuration once each has been validated individually.
**Lookback window tuning**
The recommended lookback windows (30 days, 30–90 days, and 90–180 days for visitors; 360 days for purchasers) are starting points. Adjust them based on your account:
* Shorter lookback windows produce smaller, more conservative Exclusion Signals
* Longer lookback windows exclude more users but may include users whose behavior is no longer relevant
* Set the purchaser lookback window to match your new-customer definition — this determines how long a past buyer stays excluded from acquisition campaigns
## Troubleshooting
**Exclusion Signals are not populating**
| Possible cause | Solution |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `innkeepr_targeting` event not verified | Open Meta Events Manager and check whether the `innkeepr_targeting` event is listed. If it shows as unverified, approve it. Signals will not populate until the event is verified. |
| Pixel not connected correctly | Verify that the correct Meta pixel ID is configured in Innkeepr |
| Insufficient size | Meta enforces a minimum size before a signal can be used — check that the source segments in Innkeepr contain enough users |
**Exclusion Signals reduce conversion volume without improving efficiency**
| Possible cause | Solution |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Lookback window too broad | Shorten the lookback window (e.g. use the 30-day visitor segment instead of the 90–180-day one) |
| Segment too large | Check the signal size in Meta Ads Manager — if the exclusion removes a large share of your targeting pool, the effective reach may be too narrow |
| Insufficient model data | Verify that enough conversion history was available when the signals were created |
**No measurable difference between test and control**
| Possible cause | Solution |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Exclusion segment too small | If a segment contains very few users, the effect on spend allocation is minimal — consider combining multiple segments |
| Insufficient test duration | Allow at least two to four weeks before drawing conclusions |
| Low conversion volume | Make sure each ad set has enough conversions for a meaningful comparison (50 or more per ad set recommended) |
**Performance drops after sales phases**
Performance drops can coincide with sales events such as Black Friday or seasonal promotions. During and after these phases, traffic composition and conversion patterns shift temporarily. Innkeepr typically detects these phases automatically and adjusts the underlying models accordingly.
If a performance drop persists for more than one to two weeks after a sales event has ended, reach out to the Innkeepr team to verify that the model has recalibrated correctly.
Learn more
* [Audience Signals](/concepts/audience-signals)
* [Set Up Seed Audiences on Meta](/guides/how-to-guides/meta)
* [Set Up Audience Signals on PMax](/guides/how-to-guides/pmax)
# Set Up Seed Audiences on Meta
Source: https://docs.innkeepr.ai/guides/how-to-guides/meta-seeds
## Overview
Seed Signals are custom or value-based audiences uploaded to Meta Ads Manager. They contain visitors ranked by predicted incremental lift based on your selected objective. Meta uses these lists as a basis for Lookalike Audiences (LALs) in ad sets.
This guide covers the setup of Seed Audiences on Meta, including audience structure, testing, and scaling.
## Prerequisites
**Technical Requirements:**
* An active connection to your Meta Ads account
* Sufficient data history for signal generation (minimum 30 days recommended)
**Timeline at a Glance:**
| Phase | Duration | What Happens |
| -------------- | --------------- | ---------------------------------------------------------- |
| Matching phase | 24–48 hours | Meta matches the uploaded users and populates the audience |
| Testing phase | 2–4 weeks | Performance comparison against broad targeting |
| Scaling phase | After 2–4 weeks | Budget reallocation based on results |
## Audience Types
Innkeepr provides two seed audience types for Meta:
**Custom Audiences**
User lists uploaded directly to Meta. These lists contain visitors ranked by predicted incremental lift based on your selected objective. The objective determines what the ranking optimizes for — for example conversion probability, customer lifetime value, or average order value. They are used as source audiences for Lookalike Audiences.
**Value-Based Audiences**
Lists of users identified by email address, where each entry has an assigned value based on predicted incremental impact. Unlike custom audiences, value-based audiences require an email address for each user — visitor-level data without email is not sufficient. Meta uses these values to build Lookalike Audiences that prioritize finding users similar to the highest-value entries, not just the full list. This gives Meta an additional signal for LAL expansion.
Email handoff to Innkeepr works via shop system integration (e.g. Shopify) or Innkeepr Identify.
**Learn more:**
* [Shop Integrations](/guides/integrations)
* [Spec: Identify](/guides/spec-identify)
## Setup Instructions
**Step 1: Create Audience Buckets**
There are different ways to use seed audiences on Meta, and not every setup works equally well across all accounts. The optimal configuration depends on factors like traffic volume, product portfolio, and spend budgets.
As of July 2026, we recommend the following setup as a starting point:
**Recommended bucket structure:**
| Bucket | Audience Type | Innkeepr Percentile | Lookalike Size | Rationale |
| ------ | -------------------- | -------------------------- | -------------- | ------------------------------------------------------------- |
| Seed 1 | Custom Audience | Top 0–10% | 5% LAL | Most selective signal, smallest but highest-quality lookalike |
| Seed 2 | Custom Audience | Top 10–20% | 5–10% LAL | Broader signal, medium-sized lookalike |
| Seed 3 | Custom Audience | Top 20–30% | 10% LAL | Broadest signal, largest lookalike for reach |
| Seed 4 | Value-Based Audience | Based on incremental value | 10% LAL | LAL expansion weighted by predicted incremental impact |
**Step 2: Upload Audiences to Meta**
1. **Create an Audience Signal** in Innkeepr for each bucket
2. **Select "Meta"** as your destination
3. **Verify events in Meta Events Manager** Innkeepr sends `innkeepr_targeting` events to your connected Meta pixel. After the first upload, the `innkeepr_targeting` event appears in your Events Manager. You need to approve the event before Meta processes the audience data. Without this approval, audiences will not populate.
4. **Create Lookalikes** in your Meta Ads Manager based on each bucket, using the recommended LAL sizes from the table above
**Step 3: Set Up the Campaign Structure**
Test Innkeepr audiences against broad targeting within a single campaign using separate ad sets.
**Campaign structure:**
| Ad Set | Targeting | Purpose |
| ------- | -------------------------------- | ---------------------- |
| Control | Broad (no audience targeting) | Baseline performance |
| Seed 1 | Bucket 1 — Top 0–10%, 5% LAL | Highest-quality signal |
| Seed 2 | Bucket 2 — Top 10–20%, 5–10% LAL | Medium signal |
| Seed 3 | Bucket 3 — Top 20–30%, 10% LAL | Broadest signal |
| Seed 4 | Bucket 4 — Value-Based, 10% LAL | Value-weighted signal |
**Important:** Keep all other variables identical across ad sets:
* Same **creatives** (images, videos, copy) in every ad set
* Same **optimization event** (e.g. Purchase, Add to Cart)
* Same **bid strategy**
* Same **placements** (or all set to Advantage+)
The only difference between ad sets should be the audience targeting. If creatives or other settings differ, performance differences cannot be attributed to the audience signal.
**Step 4: Set Budget Allocation**
Start all ad sets with the **same daily budget** using **ad set budget optimization (ABO)**. When testing new signals, we do not recommend using campaign budget optimization (CBO / Advantage Campaign Budget), as CBO can sometimes shift spend unpredictably, making it difficult to compare performance in the beginning. Later on, however, CBO is definitely an option for scaling.
After 1–2 weeks, you can begin scaling individual ad sets based on observed performance (see Monitor & Optimize).
## Monitor & Optimize
**Weeks 1–2: Observation Phase**
* Do **not** adjust budgets, bids, or creatives during the initial learning phase
* Monitor that all ad sets are **spending their allocated budget** and exiting the learning phase
* Verify that conversions are being tracked correctly across all ad sets
**Weeks 2–4: Evaluation**
* Compare **ROAS, new customer share, and AOV** across ad sets
* Identify which buckets outperform broad targeting and by how much
* If a bucket underperforms broad consistently, it can be paused
**After Week 4: Dynamic Scaling**
Once you have sufficient data (2–4 weeks minimum), begin scaling:
* **Increase budget** on the best-performing Innkeepr ad sets incrementally (20–30% per increase, not more)
* **Measure how much additional spend** the Innkeepr audiences can absorb while maintaining comparable performance to broad
* The goal is to determine what share of total campaign spend Innkeepr audiences can cover at equal or better performance than broad targeting
* Continue monitoring after each budget increase — allow 3–5 days for Meta's algorithm to stabilize before evaluating
> **Scaling question to answer:** How much additional spend can Innkeepr audiences absorb compared to broad targeting, at the same or better CPA/ROAS? This determines the incremental budget capacity that Innkeepr unlocks for your Meta campaigns.
## Best Practices
**Creative Isolation**
The test is only valid if creatives are identical across all ad sets. If you want to test new creatives or add additional creatives during the test, add them to all ad sets at the same time. Never add creatives to only some ad sets — this makes performance differences between ad sets unattributable.
**Lookalike Size Selection**
The recommended LAL sizes (1%, 5–10%, 10%) are starting points. Depending on your market size and target geography, you may need to adjust:
* Smaller markets (e.g. single country, DACH): start with 1%, 3%, 5%
* Larger markets (e.g. EU-wide, US): 1%, 5–10%, 10% works well
## Troubleshooting
**Audiences Not Populating**
| Possible Cause | Solution |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `innkeepr_targeting` event not verified | Open Meta Events Manager and check if the `innkeepr_targeting` event is listed. If it shows as unverified, approve it. Audiences will not populate until the event is verified. |
| Pixel not connected correctly | Verify that the correct Meta pixel ID is configured in Innkeepr |
| Insufficient audience size | Meta requires a minimum audience size — check that the source audience in Innkeepr contains enough users |
**All Buckets Underperform Broad**
| Possible Cause | Solution |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Insufficient data in Innkeepr model | Verify that enough conversion history was available when audiences were created |
| LAL sizes too narrow | Test with broader LAL sizes (e.g. 5% instead of 1%) |
| Audience stale | Check if corresponding targeting events from Innkeepr arrive at the correct pixel and that the events are verified |
**Performance Drops After Sales Phases**
Performance drops can coincide with sales events (e.g. Black Friday, seasonal promotions). During and after these phases, audience composition and conversion patterns shift temporarily. Innkeepr typically detects these phases automatically and adjusts the underlying models accordingly.
If a performance drop persists for more than 1–2 weeks after a sales event has ended, reach out to the Innkeepr team to verify that the model has recalibrated correctly.
Learn more
* [Audience Signals](/concepts/audience-signals)
* [Set Up Audience Signals on PMax](/guides/how-to-guides/pmax)
* [Set Up Conversion Signals on Google](/concepts/conversion-signals)
# Set Up Seed Audiences on Performance Max
Source: https://docs.innkeepr.ai/guides/how-to-guides/pmax-seeds
## Overview
Audience signals give Performance Max (PMax) campaigns targeting guidance. In practice, PMax audience signals are often filled with whatever lists an account already has — site visitors, customers, in-market and affinity segments — without a clear reason for why each one belongs there.
Innkeepr Seed Signals, by contrast, contain users with high predicted incremental conversion probability — users whose conversion depends on ad exposure, rather than users who would convert anyway.
This guide covers the setup of Seed Signals on Performance Max, including audience structure, testing, and scaling.
## Prerequisites
**Technical requirements:**
* An active connection to your Google Ads account
* Sufficient data history for signal generation (30 days minimum recommended)
**Timeline at a glance:**
| Phase | Timeframe | What happens |
| ------------------- | ----------- | ------------------------------------------------------------------------ |
| Signal sync | 24–48 hours | The signal is synced via GA4 and becomes available in Google Ads |
| Learning phase | Weeks 1–4 | Google's algorithm adapts to the new signals — no changes, no evaluation |
| Stabilization phase | Weeks 4–8 | Spend distribution and bidding settle; results are directional only |
| Evaluation phase | Weeks 8–12 | Reliable data for the test-vs-control comparison |
Do not evaluate performance before the 60-day mark. PMax needs time to collect data, optimize bid strategies, and stabilize across inventory types. Early results are unreliable.
## How Seed Signals Work
A Seed Signal provides Google with a reference group of users. Google then finds additional users with similar characteristics to target. Innkeepr builds Seed Signals from users with high predicted incremental conversion probability, so the lookalike expansion is based on incrementality rather than general conversion likelihood.
Before configuring your Seed Signals, it helps to understand what each parameter controls:
| Parameter | What it does | Example |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Lookback window** | How far back Innkeepr analyzes user behavior to build the signal. Shorter windows reflect recent behavior; longer windows include more historical data. | 30 days = recent activity. 90 days = longer-term behavioral patterns. |
| **Percentile threshold** | Which share of users to include, ranked by predicted incremental conversion probability. Lower percentages are more selective. | Top 50% = broader signal. Top 30% = more selective signal. |
| **Conversion lag** | Accounts for products where purchases happen days or weeks after the initial interaction. Without it, the model may undercount users who convert later. | No lag = fast-converting products (fashion, FMCG). 180 days = longer purchase cycles (insurance, furniture). |
## Setup Instructions
**Step 1: Design Your Campaign Structure**
**Why a campaign split and not an asset group split?**
As of February 2026, Google does not provide access to click-based performance data at the asset group level through the API. Only campaign-level data includes full-funnel metrics (clicks, CTR, CPC, conversions, ROAS). Testing in separate campaigns is the only way to compare performance accurately.
**Budget allocation:**
| Campaign | Budget share | Purpose |
| --------------------------------- | ------------ | ----------------------- |
| Test (with Innkeepr Seed Signals) | 20–30% | Measures signal impact |
| Control (without Seed Signals) | 70–80% | Baseline for comparison |
**Why not 50/50?** A smaller test budget reduces risk during the learning phase while still generating enough conversion volume for comparison. Increase the test share once you have enough data to evaluate results.
**Step 2: Choose Your Signal Configurations**
Start with one configuration per test campaign. Because click-based metrics are not available at the asset group level (see Step 1), running several configurations side by side inside one test campaign cannot be evaluated reliably — each configuration you want to compare needs its own campaign.
**Recommended starting configurations:**
| Configuration | Lookback | Percentile | Conversion lag | Best for |
| ------------- | -------- | ---------- | -------------- | ---------------------------------------- |
| A | 30 days | Top 50% | None | Fast-converting products (fashion, FMCG) |
| B | 30 days | Top 50% | 180 days | Products with delayed purchase decisions |
| C | 90 days | Top 30% | 180 days | High-value, long-consideration products |
**Not sure which configuration fits your use case?** Contact our team — we can help determine the right parameters based on your conversion data and product categories.
**Step 3: Create and Apply Seed Signals in Innkeepr**
1. **Create the signal** in Innkeepr based on your selected configuration
2. **Select "Google Analytics"** as the connection — the signal is synced via GA4 and then becomes available in your linked Google Ads account
3. **Set the signal type** to **Seed**
4. **Configure the parameters** — set the lookback window, percentile threshold, and conversion lag according to your chosen configuration
5. **Link the signal** to the asset groups in your test campaign in Google Ads
**Step 4: Configure Audience Signals in Google Ads**
In the **Audience signals** field on your asset groups, include only the following:
**Keep:**
* **Innkeepr Seed Signals** — your primary targeting guidance
* **Search terms** — custom search themes that are relevant to your products
**Remove:**
* **Demographics** (age, gender, household income, parental status) — these restrict the signal unnecessarily and overlap with what Google already optimizes for
* **Interests and detailed demographics** (in-market and affinity segments) — these dilute the Innkeepr signal with broad Google segments
* **Other first-party user lists** (CRM uploads, website visitors, customer match lists) — mixing other sources with Innkeepr Seed Signals makes it impossible to attribute performance to a specific signal source
The goal is to isolate the Innkeepr Seed Signal as the primary targeting guidance. Additional inputs introduce noise and make it difficult to measure the effect of the signal.
**Step 5: Configure Campaign Settings**
Ensure parity between the test and control campaigns:
* **Identical target ROAS (tROAS)** across both campaigns — a mismatched tROAS invalidates the comparison (see Best Practices below)
* **Proportional daily budgets** — 20–30% for the test campaign, 70–80% for the control campaign
* **Identical asset groups** in both campaigns, except for the Seed Signal in the test campaign
* **Identical inventory types** enabled across both campaigns (Search, Display, Shopping, Video, Discover)
**Step 6: Pre-Launch Checklist**
Before activating your campaigns, verify that:
* The test and control campaigns have **identical tROAS** values
* The budget split is **20–30% test / 70–80% control**
* Seed Signals are applied **only** to the test campaign's asset groups
* Asset groups (products, creatives, ad copy) are **identical** across both campaigns
* **Inventory types match** across both campaigns
* **Conversion tracking** is verified and capturing all relevant conversions
* The Innkeepr **signal size** is **sufficiently large** (check in the Innkeepr dashboard)
## Monitor & Optimize
**Weeks 1–4: Learning phase (hands off)**
* Do **not** adjust tROAS, budgets, or signals during the initial learning phase
* Review the **PMax placement report** weekly to understand spend distribution
* Expect inventory shifts — campaigns with Seed Signals may allocate more spend to Display and Video early on. This is expected behavior.
**Weeks 4–8: Stabilization phase (monitor, no conclusions)**
* Check **ROAS, CPA, and conversion volume** at the campaign level (test vs. control), but treat the numbers as directional only — the campaign is still learning
* If performance is significantly off target, make **small adjustments** (a 10–20% tROAS change) — but always adjust tROAS on **both** the test and the control campaign equally, otherwise the campaign with the higher tROAS will lose spend
* Allow **7–14 days** after any adjustment before re-evaluating
**Weeks 8–12: Evaluation phase**
* Compare **ROAS, CPA, and conversion volume** between the test and control campaign
* Aim for **50 or more conversions per campaign** before drawing conclusions
* If the test campaign outperforms the control campaign, increase its budget share and allow one to two weeks for the campaigns to stabilize
## Best Practices
**Target ROAS alignment**
Set identical tROAS values across the test and control campaigns. Google Ads gives more bidding flexibility to campaigns with a lower tROAS, which skews results and makes it difficult to isolate the effect of the Seed Signal. If you need to adjust tROAS, always adjust both campaigns equally — otherwise the campaign with the higher tROAS will receive less spend.
* Use your standard tROAS as the baseline for both campaigns
* Only adjust tROAS if **both** campaigns deviate from target, and always by the same margin
* Align the tROAS value itself with your business objectives and historical performance
**Signal isolation**
The test is only valid if the Seed Signal is the single difference between the two campaigns. Do not add other audience signal inputs, change creatives in only one campaign, or enable different inventory types mid-test.
## Troubleshooting
**ROAS below target after 60 or more days**
| Check | Action |
| ---------------------- | ------------------------------------------------------------------------------------------- |
| Inventory distribution | Review the placement report — is spend concentrated in low-performing channels? |
| Signal configuration | Confirm that the Seed Signal configuration matches your campaign objective and product type |
| tROAS setting | Increase it by 10–20% to push Google toward higher-quality inventory |
| Conversion tracking | Verify that all conversions are captured correctly |
**Spend concentrated in Display and Video**
This is common in the first 30–45 days. Before making changes, review actual ROAS — Display and Video placements may be converting efficiently despite the inventory shift.
If ROAS is genuinely below target, increase tROAS, temporarily reduce the budget, and wait 7–14 days for PMax to rebalance.
**Campaign still in the learning phase after 60 or more days**
| Possible cause | Solution |
| --------------------- | ------------------------------------------------------------------------- |
| Budget too low | Increase the daily budget to accelerate data collection |
| tROAS too restrictive | Lower the tROAS to allow broader bid participation |
| Insufficient demand | Verify that the products have adequate search volume |
| Too many campaigns | Consolidate — small budgets spread across many campaigns prevent learning |
**Low conversion volume in the test campaign**
| Possible cause | Solution |
| ---------------------- | ------------------------------------------------------------------------------------------------ |
| Signal too restrictive | Broaden the percentile from Top 30% to Top 50%, or extend the lookback window from 30 to 90 days |
| Signal size too small | Check the signal size in the Innkeepr dashboard |
| Signal not applied | Verify that the Seed Signal is linked to the correct asset groups |
| Insufficient time | Some configurations need 60 days or more — wait before drawing conclusions |
Learn more
* [Audience Signals](/concepts/audience-signals)
* [Set Up Seed Signals on Meta](/guides/how-to-guides/meta)
* [Set Up Exclusion Signals on Meta](/guides/how-to-guides/meta-exclusions)
* [Set Up Conversion Signals on Google](/guides/how-to-guides/google-ads-conversions)
* [Spec: Identify](/connections/spec-identify)
# Set Up Exclusion Audiences on TikTok
Source: https://docs.innkeepr.ai/guides/how-to-guides/tiktok-exclusions
## Overview
Exclusion Signals identify users with low or negative predicted incrementality. These users either do not convert at all or convert regardless of ad exposure — in both cases, excluding them from campaigns prevents spend on users where advertising has no measurable effect.
This guide covers the setup of Exclusion Signals on TikTok, including configuration, testing, and scaling.
## Prerequisites
**Technical requirements:**
* An active connection to your TikTok Ads account
* Sufficient data history for signal generation (30 days minimum recommended)
* Email addresses (`email` or `email_sha256`) written to user profiles via Innkeepr Identify — see below
Unlike Meta, TikTok audiences are matched exclusively by **email address**. Every user that should be excluded on TikTok must have an `email` or `email_sha256` trait on their profile. Innkeepr matches users to TikTok accounts using this identifier — visitor-level data without an email cannot be uploaded or matched.
Write the email to the profile with an [Spec: Identify](/connections/spec-identify) call, either as a plain `email` trait or as a SHA256-hashed `email_sha256` trait. Both are accepted; if you hash client-side, use a lowercase, trimmed email and SHA256. Email handoff can also happen automatically via a shop system integration (e.g. Shopify).
**Timeline at a glance:**
| Phase | Duration | What happens |
| -------------- | --------------- | ----------------------------------------------------------- |
| Matching phase | 24–48 hours | TikTok matches the uploaded emails and populates the signal |
| Testing phase | 2–4 weeks | Performance comparison against the control ad group |
| Scaling phase | After 2–4 weeks | Rollout to additional campaigns based on results |
## How Exclusion Signals Work
Innkeepr ranks users by predicted incremental lift for the objective you select — conversion probability, customer lifetime value, or average order value. Users at the bottom of that ranking show low or negative treatment effects: advertising has no measurable impact on whether they reach the objective. By excluding these users, the remaining budget is concentrated on users where advertising makes a difference.
Exclusion Signals are applied as exclusions at the ad group level in TikTok Ads Manager. They do not change targeting — they remove specific users from the existing targeting pool.
## Setup Instructions
**Step 1: Ensure Email Coverage**
Before creating Exclusion Signals, confirm that the users you want to exclude carry an `email` or `email_sha256` trait. Recent purchasers and existing customers are the most important to exclude — make sure Identify calls with email fire on checkout, registration, and login so these users are matchable on TikTok.
**Step 2: Create Exclusion Signals**
Exclusion Signals are built from different user segments, each with its own lookback window. The segments identify groups of identified users where ad exposure is unlikely to have an incremental impact.
There are different ways to configure Exclusion Signals, and not every setup works equally well across all accounts. The optimal configuration depends on factors such as conversion volume, product category, and overlap with your existing audiences.
As of March 2026, we recommend the following segments as a starting point.
**Recommended segments:**
Because TikTok can only exclude email-matched users, the recommended setup centers on **purchasers**, split into recency tiers so you can tune how aggressively you suppress recent versus older buyers, plus one segment for identified non-purchasers that Innkeepr ranks as low-incrementality.
| Segment | Lookback window | Description |
| ----------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purchasers (recent) | 0–90 days | Customers who bought recently — they have just converted and are the least likely to be incrementally re-acquired through paid ads |
| Purchasers (older) | 90–360 days | Customers who bought earlier in the year — set the upper bound to match how your business defines a new customer (for example, a shorter window if repeat purchases within the year are still worth re-acquiring) |
| Identified low-incrementality users | 30–180 days | Logged-in or registered users **with an email on file** whom Innkeepr ranks as low or negative incremental — the closest email-matchable equivalent to Meta's anonymous visitor exclusions |
Each segment is created in Innkeepr and uploaded to TikTok. Innkeepr sends the matched email identifiers to your connected TikTok account, and TikTok populates the audience once matching completes (typically 24–48 hours).
**Step 3: Set Up the Campaign Structure**
Test Exclusion Signals within a single campaign using separate ad groups. Both the control and the test ad group use the same base targeting and your existing default exclusions. The test ad group adds the Exclusion Signals on top.
**Campaign structure:**
| Ad group | Targeting | Exclusions | Purpose |
| -------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
| Control | Broad targeting | Your default exclusions | Baseline performance |
| Test | Broad targeting (same as control) | Your default exclusions + Innkeepr Exclusion Signals (Purchasers 0–90d, Purchasers 90–360d, Identified low-incrementality 30–180d) | Measures the impact of the Exclusion Signals |
Keep all other variables identical across ad groups:
* The same **creatives** (videos, copy) in every ad group
* The same **optimization event** (e.g. Complete Payment, Add to Cart)
* The same **bid strategy**
* The same **placements**
* The same **base targeting** — the only difference is the added Exclusion Signals
**Step 4: Set Budget Allocation**
Start both ad groups with the **same daily budget** at the **ad group level**. Do not use Campaign Budget Optimization (CBO) during the test phase — CBO shifts spend unpredictably between ad groups, which makes it difficult to compare performance.
After one to two weeks, you can begin adjusting budgets based on observed performance (see Monitor & Optimize).
## Monitor & Optimize
**Weeks 1–2: Observation phase**
* Do **not** adjust budgets, bids, or creatives during the initial learning phase
* Check that both ad groups are **spending their allocated budget** and exiting the learning phase
* Verify that conversions are tracked correctly across both ad groups
**Weeks 2–4: Evaluation**
* Compare **ROAS, new customer share, and AOV** between the control and the test ad group
* The impact of Exclusion Signals depends on the objective and the business model. Exclusion Signals can improve ROAS by removing low-incrementality spend, but they can also shift the new customer ratio — for example, excluding past purchasers concentrates budget on acquisition
* If the test ad group reduces conversion volume significantly without improving any of these metrics, the exclusion segments may be too broad — consider adjusting the lookback windows
**After week 4: Rollout**
Once you have identified the best-performing exclusion segments:
* **Apply the Exclusion Signals** to your other active campaigns on TikTok
* **Combine multiple segments** — you can apply all exclusion segments to the same ad group simultaneously
* **Monitor performance** after rollout — allow one to two weeks for each campaign to stabilize
* Exclusion Signals can be combined with Seed Signals in the same campaign — apply seed-based lookalikes as targeting and Exclusion Signals as exclusions on the same ad groups
## Best Practices
**Maintain Email Coverage**
An exclusion is only as complete as your email coverage. Users you want to exclude but who have no `email` or `email_sha256` trait cannot be matched on TikTok and will still be reachable by your ads. Keep Identify calls firing with email on checkout, registration, and login so recent purchasers and existing customers are reliably excluded.
**Creative isolation**
The test is only valid if the creatives are identical across all ad groups. If you want to test new creatives or add additional creatives during the test, add them to all ad groups at the same time. Never add creatives to only some ad groups — this makes performance differences between ad groups unattributable.
**Combining with Seed Signals**
Exclusion Signals and Seed Signals serve complementary purposes: Seed Signals direct spend toward high-incrementality users, while Exclusion Signals remove low-incrementality users from the targeting pool. Using both at the same time is the recommended configuration once each has been validated individually.
**Lookback window tuning**
The recommended lookback windows (0–90 days and 90–360 days for purchasers; 30–180 days for identified users) are starting points. Adjust them based on your account:
* Shorter lookback windows produce smaller, more conservative Exclusion Signals
* Longer lookback windows exclude more users but may include users whose behavior is no longer relevant
* Set the purchaser lookback window to match your new-customer definition — this determines how long a past buyer stays excluded from acquisition campaigns
## Troubleshooting
**Exclusion Signals are not populating**
| Possible cause | Solution |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| No email on profiles | TikTok can only match users with an `email` or `email_sha256` trait. Verify that Identify calls are writing email to the profiles used for the upload. |
| TikTok account not connected correctly | Verify that the correct TikTok Ads account is connected in Innkeepr and has permission to upload audiences |
| Insufficient size | TikTok enforces a minimum size before a signal can be used — check that the source segments in Innkeepr contain enough users with email |
| Matching still in progress | Allow 24–48 hours after upload for TikTok to finish matching |
**Exclusion Signals reduce conversion volume without improving efficiency**
| Possible cause | Solution |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Lookback window too broad | Shorten the lookback window (e.g. use the 0–90-day purchaser segment instead of the 90–360-day one) |
| Segment too large | Check the signal size in TikTok Ads Manager — if the exclusion removes a large share of your targeting pool, the effective reach may be too narrow |
| Insufficient model data | Verify that enough conversion history was available when the signals were created |
**No measurable difference between test and control**
| Possible cause | Solution |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Exclusion segment too small | If a segment matches very few users, the effect on spend allocation is minimal — consider combining multiple segments or improving email coverage |
| Insufficient test duration | Allow at least two to four weeks before drawing conclusions |
| Low conversion volume | Make sure each ad group has enough conversions for a meaningful comparison (50 or more per ad group recommended) |
**Performance drops after sales phases**
Performance drops can coincide with sales events such as Black Friday or seasonal promotions. During and after these phases, traffic composition and conversion patterns shift temporarily. Innkeepr typically detects these phases automatically and adjusts the underlying models accordingly.
If a performance drop persists for more than one to two weeks after a sales event has ended, reach out to the Innkeepr team to verify that the model has recalibrated correctly.
Learn more
* [Set Up Seed Audiences on TikTok](/guides/how-to-guides/tiktok-seeds)
* [Set Up Exclusion Signals on Meta](/guides/how-to-guides/meta-exclusions)
* [Audience Signals](/concepts/audience-signals)
* [Spec: Identify](/connections/spec-identify)
# Set Up Seed Audiences on TikTok
Source: https://docs.innkeepr.ai/guides/how-to-guides/tiktok-seeds
## Overview
Seed Signals are custom audience lists uploaded to TikTok Ads Manager. They contain users ranked by predicted incremental lift based on your selected objective. TikTok uses these lists as a basis for Lookalike Audiences in ad groups.
This guide covers the setup of Seed Audiences on TikTok, including audience structure, testing, and scaling.
## Prerequisites
**Technical Requirements:**
* An active connection to your TikTok Ads account
* Sufficient data history for signal generation (minimum 30 days recommended)
* Email addresses (`email` or `email_sha256`) written to user profiles via Innkeepr Identify — see below
Unlike Meta, TikTok audiences are matched exclusively by **email address**. Every user that should be included in a TikTok upload must have an `email` or `email_sha256` trait on their profile. Innkeepr matches users to TikTok accounts using this identifier — visitor-level data without an email cannot be uploaded or matched.
Write the email to the profile with an [Spec: Identify](/connections/spec-identify) call, either as a plain `email` trait or as a SHA256-hashed `email_sha256` trait. Both are accepted; if you hash client-side, use a lowercase, trimmed email and SHA256. Email handoff can also happen automatically via a shop system integration (e.g. Shopify).
**Timeline at a Glance:**
| Phase | Duration | What Happens |
| -------------- | --------------- | ------------------------------------------------------------- |
| Matching phase | 24–48 hours | TikTok matches the uploaded emails and populates the audience |
| Testing phase | 2–4 weeks | Performance comparison against broad targeting |
| Scaling phase | After 2–4 weeks | Budget reallocation based on results |
## Audience Types
On TikTok, Innkeepr provides seed audiences as **Custom Audiences** — user lists ranked by predicted incremental lift based on your selected objective. The objective determines what the ranking optimizes for — for example conversion probability, customer lifetime value, or average order value. These lists are used as source audiences for TikTok Lookalike Audiences.
Because TikTok matches on email, each entry in a seed audience requires an `email` or `email_sha256` trait. Users without an email are dropped before upload.
**Email handoff to Innkeepr works via:**
* [Innkeepr Identify](/connections/spec-identify) — write `email` or `email_sha256` as a trait
* Shop system integration (e.g. Shopify)
## Setup Instructions
**Step 1: Ensure Email Coverage**
Before creating audiences, confirm that the users you want to upload carry an `email` or `email_sha256` trait. The higher your email coverage, the larger and more accurate the resulting seed audience. If coverage is low, prioritize sending Identify calls with email on registration, login, and checkout.
**Step 2: Create Audience Buckets**
There are different ways to use seed audiences on TikTok, and not every setup works equally well across all accounts. The optimal configuration depends on factors like traffic volume, product portfolio, and spend budgets.
As of July 2026, we recommend the following setup as a starting point:
**Recommended bucket structure:**
| Bucket | Audience Type | Innkeepr Percentile | Lookalike Size | Rationale |
| ------ | --------------- | ------------------- | --------------- | ------------------------------------------------------------- |
| Seed 1 | Custom Audience | Top 0–10% | 5% Lookalike | Most selective signal, smallest but highest-quality lookalike |
| Seed 2 | Custom Audience | Top 10–20% | 5–10% Lookalike | Broader signal, medium-sized lookalike |
| Seed 3 | Custom Audience | Top 20–30% | 10% Lookalike | Broadest signal, largest lookalike for reach |
The logic: more selective source audiences (smaller percentile) are paired with smaller lookalikes to maintain signal quality. Broader source audiences can support larger lookalikes because the expansion is less sensitive to individual user variation.
There is no Value-Based bucket on TikTok. On Meta, a fourth value-weighted bucket is used for LAL expansion — TikTok's lookalike modeling does not accept per-user values, so the value signal is applied by pre-segmenting the source list instead.
TikTok requires a minimum matched audience size before an audience can be used. For Lookalike Audiences, TikTok recommends a matched seed of at least 1,000–5,000 users. If a percentile bucket matches fewer users than that, widen the percentile range or improve email coverage.
**Step 3: Upload Audiences to TikTok**
1. **Create an Audience Signal** in Innkeepr for each bucket
2. **Select "TikTok Ads"** as your destination and set the Audience Type to `Seed`
3. **Upload** — Innkeepr sends the matched email identifiers to your connected TikTok account
4. **Wait 24–48 hours** for TikTok to match the emails and populate the Custom Audience
5. **Create Lookalike Audiences** in TikTok Ads Manager based on each uploaded bucket, using the recommended lookalike sizes from the table above
**Step 4: Set Up the Campaign Structure**
Test Innkeepr audiences against broad targeting within a single campaign using separate ad groups.
**Campaign structure:**
| Ad Group | Targeting | Purpose |
| -------- | -------------------------------------- | ---------------------- |
| Control | Broad (no audience targeting) | Baseline performance |
| Seed 1 | Bucket 1 — Top 0–10%, 5% Lookalike | Highest-quality signal |
| Seed 2 | Bucket 2 — Top 10–20%, 5–10% Lookalike | Medium signal |
| Seed 3 | Bucket 3 — Top 20–30%, 10% Lookalike | Broadest signal |
**Important:** Keep all other variables identical across ad groups:
* Same **creatives** (videos, copy) in every ad group
* Same **optimization event** (e.g. Complete Payment, Add to Cart)
* Same **bid strategy**
* Same **placements**
The only difference between ad groups should be the audience targeting. If creatives or other settings differ, performance differences cannot be attributed to the audience signal.
**Step 5: Set Budget Allocation**
Start all ad groups with the **same daily budget** at the **ad group level**. When testing new signals, we do not recommend using Campaign Budget Optimization (CBO), as CBO can shift spend unpredictably between ad groups, making it difficult to compare performance in the beginning. Later on, however, CBO is an option for scaling.
After 1–2 weeks, you can begin scaling individual ad groups based on observed performance (see Monitor & Optimize).
## Monitor & Optimize
**Weeks 1–2: Observation Phase**
* Do **not** adjust budgets, bids, or creatives during the initial learning phase
* Monitor that all ad groups are **spending their allocated budget** and exiting the learning phase
* Verify that conversions are being tracked correctly across all ad groups
**Weeks 2–4: Evaluation**
* Compare **ROAS, new customer share, and AOV** across ad groups
* Identify which buckets outperform broad targeting and by how much
* If a bucket underperforms broad consistently, it can be paused
**After Week 4: Dynamic Scaling**
Once you have sufficient data (2–4 weeks minimum), begin scaling:
* **Increase budget** on the best-performing Innkeepr ad groups incrementally (20–30% per increase, not more)
* **Measure how much additional spend** the Innkeepr audiences can absorb while maintaining comparable performance to broad
* The goal is to determine what share of total campaign spend Innkeepr audiences can cover at equal or better performance than broad targeting
* Continue monitoring after each budget increase — allow 3–5 days for TikTok's algorithm to stabilize before evaluating
> **Scaling question to answer:** How much additional spend can Innkeepr audiences absorb compared to broad targeting, at the same or better CPA/ROAS? This determines the incremental budget capacity that Innkeepr unlocks for your TikTok campaigns.
## Best Practices
**Maintain Email Coverage**
Seed quality on TikTok is bounded by how many of your ranked users carry a matchable email. Keep Identify calls firing with `email` or `email_sha256` on registration, login, and checkout so audiences stay large and current. Falling email coverage directly shrinks match rates and lookalike quality.
**Creative Isolation**
The test is only valid if creatives are identical across all ad groups. If you want to test new creatives or add additional creatives during the test, add them to all ad groups at the same time. Never add creatives to only some ad groups — this makes performance differences between ad groups unattributable.
**Lookalike Size Selection**
The recommended lookalike sizes (5%, 5–10%, 10%) are starting points. Depending on your market size and target geography, you may need to adjust:
* Smaller markets (e.g. single country, DACH): start with 1%, 3%, 5%
* Larger markets (e.g. EU-wide, US): 5%, 5–10%, 10% works well
## Troubleshooting
**Audiences Not Populating**
| Possible Cause | Solution |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| No email on profiles | TikTok can only match users with an `email` or `email_sha256` trait. Verify that Identify calls are writing email to the profiles used for the upload. |
| TikTok account not connected correctly | Verify that the correct TikTok Ads account is connected in Innkeepr and has permission to upload audiences |
| Insufficient audience size | TikTok requires a minimum audience size (typically 1,000 matched users) — check that the source audience in Innkeepr contains enough users with email |
| Matching still in progress | Allow 24–48 hours after upload for TikTok to finish matching |
**Low Match Rate**
| Possible Cause | Solution |
| --------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Poorly formatted emails | Ensure emails are lowercase and trimmed before hashing; for `email_sha256` use SHA256 of the normalized email |
| Stale emails | Verify emails are current and actively used by your customers |
| Audience skews off-platform | Confirm that users in the audience are likely TikTok users (platform demographics) |
**All Buckets Underperform Broad**
| Possible Cause | Solution |
| ----------------------------------- | ----------------------------------------------------------------------------------- |
| Insufficient data in Innkeepr model | Verify that enough conversion history was available when audiences were created |
| Lookalike sizes too narrow | Test with broader lookalike sizes (e.g. 10% instead of 5%) |
| Low email coverage | A small matched seed limits lookalike quality — improve email coverage via Identify |
**Performance Drops After Sales Phases**
Performance drops can coincide with sales events (e.g. Black Friday, seasonal promotions). During and after these phases, audience composition and conversion patterns shift temporarily. Innkeepr typically detects these phases automatically and adjusts the underlying models accordingly.
If a performance drop persists for more than 1–2 weeks after a sales event has ended, reach out to the Innkeepr team to verify that the model has recalibrated correctly.
Learn more
* [Set Up Exclusion Signals on TikTok](/guides/how-to-guides/tiktok-exclusions)
* [Set Up Seed Audiences on Meta](/guides/how-to-guides/meta-seeds)
* [Audience Signals](/concepts/audience-signals)
* [Spec: Identify](/connections/spec-identify)
# Welcome to Innkeepr
Source: https://docs.innkeepr.ai/home/welcome
Learn how to implement Innkeepr as your signal optimization layer-connecting customer interaction data with your marketing stack to deliver incrementality-optimized signals.
Understand how Innkeepr works, plan your implementation, and configure signal flows to your marketing platforms.
## How can Innkeepr help you?
Integrate tracking from your website, app, and backend systems to feed Innkeepr's signal engine.
Deploy predictive audience segments to Google, Meta, TikTok, and Amazon based on forecasted incremental value.
Transform raw interaction data into causal signals that guide platform algorithms toward true incremental growth.
Weight conversion values by incremental contribution so bidding algorithms learn what actually drives growth.
## Get Data into Innkeepr
Innkeepr's tracking spec defines how to capture and structure behavioral data from your digital properties. This data flows into our causal engine to generate incrementality-optimized signals for your marketing platforms.
Use Track, Page, Identify, and other standard calls to capture user interactions across your properties.
Structure your events with the right traits and properties to enable accurate signal generation.
Reference implementation examples for common platforms and use cases to ensure clean data flow.
# Cookie Consent
Source: https://docs.innkeepr.ai/legal/cookies
## English
**Description of the Service**
Innkeepr allows usage data to be collected and analyzed for improved advertising purposes. It enables the integration of data from various tracking and analytics tools to optimize the targeting of advertising content.
**Processing Company**
Innkeepr UG
Senefelderstr. 35, 09126 Chemnitz, Germany
**Data Protection Officer of the Processing Company**
Below you will find the contact details for the Data Protection Officer of the processing company.
[https://innkeepr.ai/privacy](https://innkeepr.ai/privacy)
**Purpose of Data Collection**
This list outlines the purposes of data collection and processing:
* Optimization of advertising content
* Analysis of user behavior
**Technologies Used**
This list includes all technologies used by Innkeepr to collect data. Typical technologies include cookies, pixels, and website tags stored in the browser.
* Tracking pixels
* Cookies
**Collected Data**
Innkeepr itself does not collect any personal data. However, users of the service have the option to submit personal data in connection with the collected usage data. The processing of such data is carried out in accordance with the respective customer's specifications and in compliance with applicable data protection regulations.
## Deutsch
**Beschreibung des Services**
Mit Innkeepr können Nutzungsdaten erfasst und für bessere Werbezwecke analysiert werden. Innkeepr ermöglicht es, Daten aus verschiedenen Tracking- und Analysetools zusammenzuführen und für eine gezieltere Aussteuerung von Werbeinhalten zu verwenden.
**Verarbeitendes Unternehmen**
Innkeepr UG
Senefelderstr. 35, 09126 Chemnitz, Deutschland
**Datenschutzbeauftragter des verarbeitenden Unternehmens**
Nachfolgend finden Sie die Kontaktmöglichkeit für den Datenschutzbeauftragten des verarbeitenden Unternehmens.
[https://innkeepr.com/privacy](https://innkeepr.com/privacy)
**Zweck der Daten**
Diese Liste stellt die Zwecke der Datenerhebung und -verarbeitung dar:
* Optimierung von Werbeinhalten
* Analyse des Nutzerverhaltens
**Genutzte Technologien**
Diese Liste enthält alle Technologien, mit denen Innkeepr Daten sammelt. Typische Technologien sind Cookies, Pixel und Webseiten-Tags, die im Browser gespeichert werden.
* Tracking-Pixel
* Cookies
**Gesammelte Daten**
Innkeepr selbst erfasst keine personenbezogenen Daten. Nutzer des Dienstes haben jedoch die Möglichkeit, personenbezogene Daten in Verbindung mit den erfassten Nutzungsdaten zu übermitteln. Die Verarbeitung dieser Daten erfolgt nach den Vorgaben des jeweiligen Kunden und unter Einhaltung geltender Datenschutzbestimmungen.
# Data Protection Statement
Source: https://docs.innkeepr.ai/legal/data-protection
## English
a) On our website, we use the web analysis service Innkeepr to analyze and regularly improve the usage of our site. The statistics obtained allow us to enhance our offerings and make them more interesting for you as users. The legal basis for using Innkeepr is Article 6, Paragraph 1, Letter f of the General Data Protection Regulation (GDPR).
b) Innkeepr uses cookies, which are stored on your computer and enable an analysis of your usage of our website. The information collected in this way is stored exclusively on EU servers. We use Innkeepr without collecting IP addresses or hardware specifications. There is no direct personal reference to the data we collect.
c) You can prevent the storage of cookies by adjusting your browser settings accordingly. However, we would like to point out that in this case, you may not be able to fully utilize all the functions of this website. The data is stored in the browser under `tjs_userData` and `tjs_sessionData`. The lifespan of the data is unlimited because there is no personal reference to delete.
## Deutsch
a) Wir nutzen auf unserer Website den Webanalysedienst Innkeepr, um die Nutzung unserer Seite analysieren und regelmäßig verbessern zu können. Über die gewonnenen Statistiken können wir unser Angebot verbessern und für Sie als Nutzer\*innen interessanter ausgestalten. Rechtsgrundlage für die Nutzung von Innkeepr ist Art. 6 Abs. 1 Buchst. f DSGVO.
b) Innkeepr verwendet Cookies, die auf Ihrem Computer gespeichert werden und die eine Analyse der Nutzung unserer Website durch Sie ermöglichen. Die so erhobenen Informationen speichern wir ausschließlich auf Servern der EU. Wir verwenden Innkeepr ohne die Erfassung von IP-Adressen oder Hardwarespezifikationen. Eine direkte Personenbeziehbarkeit der von uns erhobenen Daten ist ausgeschlossen.
c) Sie können die Speicherung der Cookies durch eine entsprechende Einstellung Ihrer Browser-Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich werden nutzen können. Die Daten werden im Browser unter `tjs_userData` und `tjs_sessionData` gespeichert. Die Lebensdauer der Daten ist unbegrenzt, da kein Personenbezug besteht, der zu löschen wäre.