---
updatedAt: 2025-06-11T08:29:39.000Z
agentTools:
  projectIndex: https://docs.fullcontact.com/llms.txt
---

# FullContact Webtag ID Service

## Groundwork

### User consent and Data use

Please ensure your consent mechanism provides notice to the user that data they submit will be shared with FullContact.

## Usage

Note: To use this application, you will need a [FullContact Webtag Key](https://docs.fullcontact.com/docs/customer-recognition-tag-copy).

Follow these steps to use this service.

1. Initialize the Customer Recognition Webtag on Page Load

```javascript
fc('init', "{{WEBTAG_KEY}}", config);
```

2. At a later time, when first party data can be identified, the following function can be called. The FIRST\_PARTY\_ID\_DATA would follow the same format as the [multi-field-requests](https://docs.fullcontact.com/docs/multi-field-request-1):

```javascript
Fullcontact.id("{{identification_event}}", `{"{FIRST_PARTY_ID_DATA}"}`);
```

3. Valid values for `identification_event` are:

| event id            | description                                                                                                                                                                                                  |
| :------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `user_registration` | Use this event when users are registering for a service for the first time and provide email or other identifying information                                                                                |
| `user_login`        | Fired when users log in using email or another identifier                                                                                                                                                    |
| `password_reset`    | Fired when users request a password reset based on email                                                                                                                                                     |
| `newsletter_signup` | Fired when users request to be subscribed to an email user                                                                                                                                                   |
| `contact_us`        | Fired when a user fills out a "Contact us" or other form where they provide email and additional identifiers                                                                                                 |
| `survey_fill`       | Fired when a user fills out a survey and provides an email or other information                                                                                                                              |
| `qp_1pidy`          | "Query Param First Party" - used by the system automatically when first party hashed email identifiers are extracted from query params when the webtag is configured with `_1pidy: true`                     |
| `other_{{custom}}`  | Used in other circumstances not provided above. "\{\{custom}}" can be a short string provided by the application, limited to a-z and no more than 32 characters. Examples: `other_newsletter` or `other_xyz` |

An example of this call would look like the following:

```javascript
Fullcontact.id("user_registration", {"emails": ["raworhashedemail@gmail.com"], "phones": ["+15551231234"]})
```

The `Fullcontact.id` function assumes an automatic, initial resolve attempt has already occurred during the init call in step 1: `fc('init', "{{WEBTAG_KEY}}", config)`. This means that there may be a personId already saved on the browser via cookies. This personId will automatically be sent along with the multi-field request to be mapped together for Webtag ID calls.

If there is no personId saved in the browser but the PII in the multi-field request resolves to an identity, a new personId will be created for the [Identity Streme](https://docs.fullcontact.com/docs/identity-streme-overview) mapping and updated in the user's browser. In cases where the multi-field PII is already mapped to a personId in your Identity Streme, the mapped personId will be returned and overwrite the personId cookie on the browser if it exists.

These response scenarios are illustrated in more depth in the table below.

| personId cookie exists? | multi-field request resolves to an identity? | identity already mapped in the ID Streme? | response code | personId saved to ID Streme and browser cookie |
| :---------------------- | :------------------------------------------- | :---------------------------------------- | :------------ | :--------------------------------------------- |
| **true**                | true                                         | false                                     | 200           | original personId from browser cookie          |
| **false**               | true                                         | false                                     | 200           | newly created personId                         |
| true OR false           | true                                         | **true**                                  | 200           | existing personId from ID Streme               |
| true OR false           | **false**                                    | NA                                        | 404           | no identity found, no personId mapped or saved |

<br/>

> 🚧 Parameter based functionality is not yet available.

## Parameter Based

If the hashed email is provided via the query parameters, via `?e=sha256(email)`, there is an ability to set up the Customer Recognition tag to automatically capture this data when available. This use case can be helpful when tracking link interactions when sending newsletters or other emails directly to your customers. This requires personalized URLs per email account, where each click-through url looks something like: `https://yourbrand.com/content?e=466527e9a353110fc5252ffbb1df0f707a5d20e4ea5f3d778e66dbd0b7c2d5c0`

**Note:** The config param `_1pidy` needs to be set to true in the existing webtag configuration, in addition to the user consent, in order to get picked up.

The full script would look like the following:

```html
<script>
(function (w, d, s, o, f, js, fjs) {
    w['FCObject'] = o; w[o] = w[o] || function () { (w[o].q = w[o].q || []).push(arguments) };
    js = d.createElement(s), fjs = d.getElementsByTagName(s)[0];
    js.id = o; js.src = f; js.async = 1; fjs.parentNode.insertBefore(js, fjs);
}(window, document, 'script', 'fc', 'https://tags.fullcontact.com/anon/fullcontact.js'));

var config = {
   _1pidy: true,
   callback: function (pid) {
// Add your js callback code here (optional)
}};

fc('init',"{{WEBTAG_KEY}}",config);
</script>
```

When the FullContact tag is configured as shown above with `_pidy: true` any hashed emails seen in a query url param will automatically be extracted and provided to the `id` service described above using an `identification_event` type of `qp_1pidy`.