> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# WeHelp as a data source
> Bring data from WeHelp to Nekt.
WeHelp is a customer experience platform used to run NPS and eNPS surveys. It collects satisfaction scores from customers and employees across email, SMS, WhatsApp, and web channels, then reports the results broken down by organizational unit and by custom attributes such as plan or segment.
## Configuring WeHelp as a Source
In the [Sources](https://app.nekt.ai/sources) tab, click on the "Add source" button located on the top right of your screen. Then, select the WeHelp option from the list of connectors.
Click **Next** and you'll be prompted to add your access.
### 1. Add account access
You'll need the API credentials of your WeHelp account, found under **Settings > Integrations > API**. The user that owns the credentials needs permission to read NPS reports.
The following configurations are available:
* **Client ID**: The Client ID of your WeHelp API integration.
* **Client Secret**: The Client Secret issued alongside the Client ID.
* **Start Date**: The earliest date from which reports will be collected. Defaults to 12 months before the first sync.
* **Period Grain**: (Default: `month`) The length of the period each report row covers. WeHelp reports figures for a requested date range rather than per response, so this setting defines the grain of every report table. Choose `month` for one row per month, which suits most accounts, or `day` for one row per day, which gives finer trends at the cost of roughly 30 times more requests.
* **Survey Audiences**: (Default: both) Which surveys to collect. `CUSTOMER` covers customer NPS and `COLLABORATOR` covers employee eNPS. Both are collected by default and are told apart by the `destination` column in every report table. Select only one to halve the number of requests.
* **Custom Fields to Break Down By**: The custom field IDs used by the `nps_data_by_custom_field` table. Leave it empty to break the NPS down by every custom field in the account. Each field adds one request per period, so narrow this list if the sync gets slow. You can look the IDs up in the `custom_fields` table.
* **Lookback Periods**: (Default: 2) How many already-collected periods to read again on every sync. A survey sent in one period is often answered in the next, which changes the earlier period's score, so recent periods are refreshed rather than left frozen. Raise it if answers frequently arrive late.
Once you're done, click **Next**.
### 2. Select streams
Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
> Tip: The stream can be found more easily by typing its name.
Select the streams and click **Next**.
### 3. Configure data streams
Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
* **Layer**: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
* **Folder**: a folder can be created inside the selected layer to group all tables being created from this new data source.
* **Table name**: we suggest a name, but feel free to customize it. You have the option to add a **prefix** to all tables at once and make this process faster!
* **Sync Type**: you can choose between INCREMENTAL and FULL\_TABLE.
* Incremental: every time the extraction happens, we'll get only the new data - which is good if, for example, you want to keep every record ever fetched.
* Full table: every time the extraction happens, we'll get the current state of the data - which is good if, for example, you don't want to have deleted data in your catalog.
Once you are done configuring, click **Next**.
### 4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters.
To define your [Trigger](https://docs.nekt.com/runs/scheduling-and-triggers), consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
Optionally, you can define some additional settings:
* Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource [here](https://docs.nekt.com/get-started/core-concepts/resource-control).
* Determine when to execute an **Additional [Full Sync](https://docs.nekt.com/get-started/core-concepts/types-of-sync#additional-full-sync)**. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Once you are ready, click **Next** to finalize the setup.
### 5. Check your new source
You can view your new source on the [Sources](https://app.nekt.ai/sources) page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you need at least one successful source run.
## How WeHelp data is organized
The WeHelp API reports aggregated figures for a requested date range. It does not expose individual survey responses, so every report table contains totals for a period rather than one row per respondent.
Each report row is stamped with the window it covers:
* `period_start` and `period_end` — the first and last day of the period. `period_start` is the incremental replication key.
* `period_grain` — `month` or `day`, matching the **Period Grain** setting.
* `destination` — `CUSTOMER` for customer NPS or `COLLABORATOR` for employee eNPS.
Reports grouped by unit identify each group by the unit **name**, not by its ID. In `nps_data_by_company_unit`, join to the `company_units` table on `name` to recover the unit ID. The `nps_sent`, `nps_conversion`, and `nps_answered` tables do carry `company_unit_id` directly.
Because a survey sent near the end of a period is often answered in the next one, NPS figures for a period keep changing for a while after it closes. The **Lookback Periods** setting re-reads recent periods on every sync so those late answers are reflected. Use an INCREMENTAL sync type to keep the refreshed rows.
# Streams and Fields
## Available streams
The table below lists every stream, its **slug** (the exact identifier to pass when creating the source via API) and a short description.
| Stream | Slug | Description |
| ---------------------- | -------------------------- | ------------------------------------------------------------------------------------ |
| Company Units | `company_units` | Organizational units (branches, franchises, departments) and their hierarchy. |
| Custom Fields | `custom_fields` | Custom person fields available to break the NPS down by. |
| NPS by Company Unit | `nps_data_by_company_unit` | NPS figures per unit and period, with score distribution and response channels. |
| NPS by Custom Field | `nps_data_by_custom_field` | The same NPS figures, broken down by the value of a custom field. |
| Surveys Sent | `nps_sent` | Send and delivery metrics per channel, covering the first send and the reminder. |
| Send Conversion | `nps_conversion` | Send-to-response conversion per unit, with the channels the answers arrived through. |
| Respondent Transitions | `nps_answered` | How repeat respondents moved between promoter, passive, and detractor. |
## Fields by stream
Below you'll find all available data streams from WeHelp and their corresponding fields:
The organizational units of the account. Units are the dimension every report is broken down by.
**Key Fields:**
* `id` - Unique identifier of the unit
* `name` - Full display name of the unit, used to identify groups in reports
* `nickname` - Short name of the unit
* `code` - Internal code the company assigns to the unit
* `parent_id` - Identifier of the parent unit, or null for a top-level unit
* `country_id` - WeHelp identifier of the unit's country
* `state_id` - WeHelp identifier of the unit's state or province
The account's custom person fields, such as plan, segment, or trainer. Use these IDs in the **Custom Fields to Break Down By** setting.
**Key Fields:**
* `id` - Unique identifier of the custom field
* `name` - Display name of the custom field as configured in WeHelp
NPS figures per unit and period: the score and its zone, how the answers were distributed, which channels they arrived through, and how many mentioned a problem or left a comment.
**Identification:**
* `company_unit_name` - Name of the unit the figures describe
* `destination` - `CUSTOMER` for NPS or `COLLABORATOR` for eNPS
* `period_start` - First day of the period, and the incremental replication key
* `period_end` - Last day of the period
* `period_grain` - Length of the period: `month` or `day`
**NPS Score:**
* `nps_value` - NPS score, from -100 to 100
* `nps_status` - Zone assigned to the score: EXCELLENCE, GOOD, IMPROVEMENT, CRISIS, or LEARNING
* `nps_total_responses` - Number of responses counted in the score
* `nps_total_promoters` - Responses scoring 9 or 10
* `nps_total_passives` - Responses scoring 7 or 8
* `nps_total_detractors` - Responses scoring 0 to 6
* `nps_total_percent_promoters` - Percentage of responses that are promoters
* `nps_total_percent_passives` - Percentage of responses that are passives
* `nps_total_percent_detractors` - Percentage of responses that are detractors
**Score Distribution:**
* `dispersion_total` - Total responses included in the distribution
* `dispersion_average` - Average score given
* `dispersion_0_total` through `dispersion_10_total` - Number of responses per score
* `dispersion_0_percent` through `dispersion_10_percent` - Percentage of responses per score
**Response Channels:**
* `answered_email` - Responses submitted through email
* `answered_sms` - Responses submitted through SMS
* `answered_site` - Responses submitted through the website
* `answered_link` - Responses submitted through a direct link
* `answered_direct` - Responses entered directly, in person or manually
* `answered_whatsapp` - Responses submitted through WhatsApp
* `answered_external` - Responses submitted through an external send
**Comments, Problems, and Forms:**
* `number_with_observation` - Responses that included a written comment
* `number_without_observation` - Responses submitted without a comment
* `srproblems_number_has_problem` - Responses that reported a problem
* `srproblems_number_hasnt_problem` - Responses that reported no problem
* `srproblems_number` - Responses that answered the problem form at all
* `srproblems_number_solved_problem` - Reported problems marked as solved
* `srproblems_number_not_solved_problem` - Reported problems still unsolved
* `number_with_touchpoints` - Responses that recorded at least one touchpoint
* `number_with_extra_forms` - Responses that also filled in an extra form
**Problem NPS:**
* `nps_problem_value`, `nps_problem_status`, `nps_problem_total_responses`, `nps_problem_total_promoters`, `nps_problem_total_passives`, `nps_problem_total_detractors`, `nps_problem_total_percent_promoters`, `nps_problem_total_percent_passives`, `nps_problem_total_percent_detractors` - The same score breakdown, restricted to responses that reported a problem
The same NPS figures as `nps_data_by_company_unit`, broken down by the value of a custom person field instead of by unit. Useful for comparing satisfaction across plans, segments, or any other attribute tracked in WeHelp.
**Identification:**
* `custom_field_id` - Identifier of the custom field the figures are broken down by
* `custom_field_name` - Display name of the custom field, for example "Plano"
* `custom_field_value` - Value this group covers, for example "INfinito"
* `destination` - `CUSTOMER` for NPS or `COLLABORATOR` for eNPS
* `period_start` - First day of the period, and the incremental replication key
* `period_end` - Last day of the period
* `period_grain` - Length of the period: `month` or `day`
**Metrics:**
This stream carries the same score, distribution, channel, comment, problem, and Problem NPS fields as the **NPS by Company Unit** stream above.
Send and delivery metrics per channel, covering both the first send and the reminder. One row per unit and channel.
Channels the account does not use still report a row with zeroes rather than being omitted.
**Identification:**
* `company_unit_id` - Identifier of the unit, returned as a string
* `company_unit_name` - Name of the unit
* `channel` - Delivery channel: `email`, `sms`, `whats_app`, or `external_send`
* `destination`, `period_start`, `period_end`, `period_grain` - Audience and period the figures cover
**First Send:**
* `amount` - Surveys queued on this channel
* `amount_sent` - Surveys actually dispatched
* `amount_delivered` - Sends confirmed as delivered
* `amount_error` - Sends that failed (bounced, invalid address, refused)
* `amount_open` - Sends the recipient opened. Always zero for SMS
* `amount_click` - Sends where the recipient clicked through to the survey
**Reminder:**
* `amount_reminder` - Reminder messages queued
* `amount_reminder_sent` - Reminder messages dispatched
* `amount_reminder_delivered` - Reminder messages delivered
* `amount_reminder_error` - Reminder messages that failed
* `amount_reminder_open` - Reminder messages opened
* `amount_reminder_click` - Reminder messages clicked through
**Totals (first send plus reminder):**
* `total`, `total_sent`, `total_delivered`, `total_error`, `total_open`, `total_click`
**Rates:**
* `percent_sent`, `percent_delivered`, `percent_error`, `percent_open`, `percent_click` - Rates for the first send
* `total_percent` - Share of all the unit's sends that used this channel
* `total_percent_sent`, `total_percent_delivered`, `total_percent_error`, `total_percent_open`, `total_percent_click` - Rates across first sends and reminders
* `amount_responses` - Total responses received by the unit in the period, used as the denominator for this channel's share
Send-to-response conversion per unit, with the split of answers across channels.
**Identification:**
* `company_unit_id` - Identifier of the unit, returned as a string
* `company_unit_name` - Name of the unit
* `destination`, `period_start`, `period_end`, `period_grain` - Audience and period the figures cover
**Conversion:**
* `conversion` - Percentage of surveys sent in the period that were answered
* `sent_amount_responses` - Surveys sent to the unit's contacts in the period
* `answered_amount_responses` - Surveys answered in the period, across every channel
**Answers by Channel:**
* `answered_amount_email`, `answered_amount_sms`, `answered_amount_site`, `answered_amount_link`, `answered_amount_direct`, `answered_amount_whatsapp`, `answered_amount_external_send` - Answers submitted through each channel
* `answered_percent_email`, `answered_percent_sms`, `answered_percent_site`, `answered_percent_link`, `answered_percent_direct`, `answered_percent_whatsapp`, `answered_percent_external_send` - Share of the unit's answers that arrived through each channel
How repeat respondents moved between promoter, passive, and detractor, comparing each respondent's score in the period against their previous one. This is the report behind WeHelp's evolution view.
**Identification:**
* `company_unit_id` - Identifier of the unit, returned as a string
* `company_unit_name` - Name of the unit
* `destination`, `period_start`, `period_end`, `period_grain` - Audience and period the figures cover
* `number_answered` - Respondents who answered in the period and had answered before
* `sr_id` - WeHelp internal survey-round identifier for the comparison
**Transitions:**
* `promoter_still_promoter` - Respondents who were promoters before and still are
* `promoter_to_passive` - Promoters who became passives
* `promoter_to_detractor` - Promoters who became detractors
* `passive_to_promoter` - Passives who became promoters
* `passive_still_passive` - Respondents who were passives before and still are
* `passive_to_detractor` - Passives who became detractors
* `detractor_to_promoter` - Detractors who became promoters
* `detractor_to_passive` - Detractors who became passives
* `detractor_still_detractor` - Respondents who were detractors before and still are
* `promoter_to_passive_percent`, `promoter_to_detractor_percent`, `passive_to_promoter_percent`, `passive_to_detractor_percent`, `detractor_to_promoter_percent`, `detractor_to_passive_percent` - Share of the previous population represented by each movement
**Current vs Previous Totals:**
* `total_promoter`, `total_passive`, `total_detractor` - Classes among the compared respondents in this period
* `old_total_promoter`, `old_total_passive`, `old_total_detractor` - The same respondents at their previous answer
**Summary:**
* `total_evolved` - Respondents who moved to a better class
* `total_remained` - Respondents who stayed in the same class
* `total_decayed` - Respondents who moved to a worse class
* `total_evolved_percent`, `total_remained_percent`, `total_decayed_percent` - The same figures as shares of the compared respondents