> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/marketing/chameleon/data-overview.md).

# Data Overview

Chameleon exposes data across ten entities — covering the in-app experiences you've built, the user segments you target, and the feedback you've collected. Here's what you can access and how to make the most of it.

## Entities at a glance

| Entity           | What it contains                                 |
| ---------------- | ------------------------------------------------ |
| Helpbars         | Configuration and metadata for help bar elements |
| Segments         | Definitions and rules for user segments          |
| URLs             | URLs being tracked in your Chameleon instance    |
| URL groups       | Logical groupings of related URLs                |
| Changes          | Audit log of edits made to Chameleon experiences |
| Launchers        | Launcher setup and targeting configuration       |
| Tooltips         | Tooltip content, targeting, and settings         |
| Tours            | Product tour steps, content, and metadata        |
| Surveys          | Survey structure, questions, and configuration   |
| Survey responses | Individual user responses to surveys             |

## Metrics and dimensions

#### Experience configuration fields (Tours, Tooltips, Launchers, Helpbars)

| Field          | Description                                      |
| -------------- | ------------------------------------------------ |
| id             | Unique identifier for the experience             |
| name           | Display name of the experience                   |
| status         | Published, draft, or archived                    |
| created\_at    | Timestamp when the experience was created        |
| updated\_at    | Timestamp of the last modification               |
| segment\_id    | ID of the user segment this experience targets   |
| url\_group\_id | ID of the URL group where the experience appears |

#### Survey and survey response fields

| Field        | Description                                 |
| ------------ | ------------------------------------------- |
| id           | Unique response ID                          |
| survey\_id   | ID of the parent survey                     |
| user\_id     | ID of the user who responded                |
| response     | The actual answer provided                  |
| created\_at  | When the response was submitted             |
| finished\_at | When the user completed the survey          |
| profile\_id  | Chameleon profile linked to this respondent |

#### Segment fields

| Field       | Description                                    |
| ----------- | ---------------------------------------------- |
| id          | Unique segment ID                              |
| name        | Segment name                                   |
| filter      | Targeting rules that define segment membership |
| created\_at | When the segment was created                   |
| updated\_at | Last time segment rules were modified          |

#### Changes fields

| Field          | Description                                         |
| -------------- | --------------------------------------------------- |
| id             | Change record ID                                    |
| kind           | Type of change (create, update, delete)             |
| created\_at    | Timestamp of the change                             |
| experience\_id | ID of the affected experience                       |
| user\_id       | ID of the Chameleon team member who made the change |

## Common combinations to use

* **Tours + Segments** — Join on `segment_id` to see which audience each tour targets, then evaluate whether targeting is consistent across experiences.
* **Surveys + Survey responses** — Join on `survey_id` to enrich raw responses with the survey name and question text for cleaner reporting.
* **Changes + Tours/Tooltips** — Join on `experience_id` to build an audit trail of who changed what and when.
* **Multiple accounts** — Use **Append** to combine Chameleon data from multiple workspaces into a single dataset.

## Use cases by role

{% tabs %}
{% tab title="Product managers" %}

* Track which tours and tooltips are live vs. draft to audit your in-app experience inventory.
* Join survey responses with user segment data to understand which cohorts are engaging with feedback prompts.
* Use the Changes entity to review what was modified before a drop in tour completion rates.
  {% endtab %}

{% tab title="Marketers" %}

* Export survey responses to Google Sheets or Looker Studio to visualize NPS or sentiment trends over time.
* Analyze which URL groups trigger the most launcher interactions to prioritize high-traffic pages.
* Send survey response data to ChatGPT or Claude to automatically categorize open-ended feedback.
  {% endtab %}

{% tab title="Customer success" %}

* Monitor segment definitions to confirm onboarding tours are targeting the right new-user cohorts.
* Pull survey responses regularly to catch negative feedback signals before they escalate.
* Combine Chameleon tour data with CRM data using Join to correlate in-app engagement with retention outcomes.
  {% endtab %}
  {% endtabs %}

## Platform-specific notes

* The **filter** parameter on the source applies specifically to segment-experience filtering and accepts `tour`, `survey`, or `launcher` as values — set this if you want to scope that entity type.
* The default record limit per page is **50** — increase this using the **Record limit** parameter if you're working with large datasets.
* Chameleon's API is incremental — use the **start date** and **end date** parameters together to define a precise sync window.
* Survey responses include a `finished_at` field only when the user completed the survey — expect null values for partial responses.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coupler.io/sources/category/marketing/chameleon/data-overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.