Getting started

Wyng Profiles is a headless API and JavaScript SDK for:

1. Progressive collection of needs and preferences data from users of your website and mobile app;
2. Powering unified preference centers where users can securely manage their needs and preferences;
3. Real-time personalization of experiences across channels and touchpoints using the data.

Profiles comprises functions for:

• Identifying users using anonymous and known IDs
• Profile stitching
• Inserting and updating data in profiles
• Accessing profiles for personalization
• Authenticating users for secure access to personal data
• Defining and accessing segments for personalization and measurement

Your data model

To get started with Profiles, you need to set up a data model in Wyng, that describes the IDs that you will use to identify website visitors and the attributes that you plan to collect and use for personalization. To set up or review your data model, visit Profiles > Data Model in your Wyng dashboard. If you do not see the Profiles option in Wyng, ask your account manager or Wyng to provide you with access.

Planning and using identifiers

For a more comprehensive discussion about effective planning and use of identifiers, review the Wyng Tech Guide, Planning and Using Identifiers with Wyng Profiles API

Key and attribute fields

Your data model in Wyng is a list of fields which a profile can contain -- including IDs and attributes. Fields have a data type, like text, set, date, or num. Fields that can be used to identify a unique user are called keys. Keys may include anonymous visitor IDs, like a Google Analytics client ID _ga, and known user identifiers, like email, customer_id, or phone_number.

The data model is managed using the configuration panel in Wyng, which generates an underlying representation, similar to this example:

{
  "strong_id": "email",
  "ids_priority": [
    "salesforce_id",
    "email",
    "uids"
  ],
  "fields": [
    {
      "id": "uids",
      "name": "Anonymous Visitor ID",
      "status": "active",
      "is_key": true
      "type": "set",
      "values": [],
      "allow_other_values": true,
      "retention_window": null,
      "relevance_window": null,
      "is_hash_field": false,
    },
    {
      "id": "email",
      "name": "Email Address",
      "status": "active",
      "is_key": true
      "type": "text",
      "values": [],
      "allow_other_values": true,
      "retention_window": null,
      "relevance_window": null,
      "is_hash_field": false,
    },
    {
      "id": "salesforce_id",
      "name": "SF User ID",
      "status": "active",
      "is_key": true
      "type": "text",
      "values": [],
      "allow_other_values": true,
      "retention_window": null,
      "relevance_window": null,
      "is_hash_field": false,
    },
    {
      "id": "traveler_activities",
      "name": "Favorite Sport",
      "status": "active",
      "is_key": false,
      "type": "set",
      "values": [
        "Football",
        "Basketball",
        "Skiing",
        "Baseball",
        "Volleyball",
        "Cricket"
      ],
      "allow_other_values": false,
      "retention_window": 365,
      "relevance_window": 365,
      "is_hash_field": false,
    },
  ]
}

Anonymous visitor ID

Your data model includes, by default, a uids field of type set, which contains an automatically generated anonymous visitor ID. This ID is generated by the Profiles SDK on a user's first visit to your website or mobile app, and stored persistently in localStorage on their device. Each new uid has a corresponding profile in Wyng, which will be used for future sessions from the same device.

Profile-stitching

The strong_id controls the automatic profile-stitching feature of Profiles. One key field in the data model is designated strong_id, and is used to identify profiles from different devices and sessions that correspond to the same unique person, and should be merged. When profile attributes are collected by the SDK, if the strong_id is present among the attributes, then any other profiles that share the strong_id will be stitched together and merged into the current user's profile.

Identity context and IDs priority

The SDK keeps an identity context for the current web session, where you can add one or more user IDs for the current web visitor. If multiple IDs are available in the identity context, ids_priority determines how IDs are prioritized when looking up the visitor profile.

For example, if ids_priority is:

"ids_priority": [
  "salesforce_id",  
  "email",
  "hashed_email",
  "uids"
]

Now, assume a user with anonymous visitor ID e23d1615c7874594b929d69c67714d09 clicks through to the website on tracked link with a hashed email, and the user's hashed_email is added to the identity context:

windows.wyng.profiles.identify({
    hashed_email: '0cba00ca3da1b283a57287bcceb17e35' 
})

// ↳ identity context = { 
//       uids: 'e23d1615c7874594b929d69c67714d09', 
//       hashed_email: '0cba00ca3da1b283a57287bcceb17e35' 
//   }

To match a profile the API will first use the available ID with the highest rank in ids_priority--in this case, hashed_email; if no match, the API will try to match with the next available ID in rank order--in this case, uids.

If no match is found after exhausting available IDs, if any data is collected during this session, a new profile will be created with hashed_email: '86E0B9E56C17CC4D12387E1949B85053FBE73BC3CE5A1188713A9D300CC6133D' and uids: 'e23d1615c7874594b929d69c67714d09'.