Gigya provides functionality for passing users' site and social information from your website to Data Management Platforms (DMP). This creates more detailed analytics and user insights, improving your understanding of your user base and allowing you to target ads on your site based on a user's dynamic information, such as age, gender, relationship status, country, likes, etc.
This generic integration solution can be implemented at different levels. In order to sync personal identity information, this solution assumes that users login/register through Gigya. However, if you are only syncing non-personal identity information (e.g., comments, shares etc.) this is not a requirement, and this solution can be used without Gigya login/registration.
This document is a general guide to integrating Gigya with Data Management Platforms.
Gigya offers two ways to pass user information to Data Management Platforms:
- Real-time data transfer
- Batch data transfer
Real-time Data Transfer
Real-time data transfer is useful when you are using Gigya's Social Login.
This mode is implemented by embedding code in your web client to catch registration and login events and pass them on to your DMP in real time. When a user logs in using Gigya's Social Login, this triggers an onLogin event which is caught by an onLogin handler which you embed into your website code. The onLogin handler passes user information on to the DMP which can then use the data for ad targeting in real-time.
However, there are few things to consider when using real-time data transfer.
Since the onLogin handler is client side code, it is unlikely to be aware of which users have logged in to the system. Therefore, it will pass on the user data to the DMP even if there is no change to the user's data since his last login. In other words, the same user data will redundantly be sent to your DMP over and over again.
The connection between your browser code and the DMP is not necessarily secure, and may be vulnerable to sniffing. Therefore, you may not send any personal identity information (e.g. name, email, address etc.) from your onLogin handler to the DMP.
For some real examples of how to implement real-time data transfer to a DMP, please refer to the following integrations:
There is a way to implement secure transfer of PII in real-time PII. You may use the UID retrieved in the onLogin handler and pass that to a server process that should be developed. This server process can access the user's PII through Gigya's Socialize APIs, and then transfer the PII server-to-server to the DMP over a secure connection.
Batch Data Transfer
Batch data transfer is useful when you are using Gigya's Registration as a Service (RaaS).
This mode is also implemented by embedding code in your web client, however, in this case, rather than sending user data directly to the DMP, the onLogin handler registers each user that has signed up (or signed in), and the user's data is passed on to the DMP periodically behind the scenes in a batch process. The batch process can be timed to run every few minutes, and so keeps your DMP up to date for ad targeting in near real-time.
Transfer of user data is done with the help of your Gigya Implementation Consultant, for the specific DMP in question.
While this mode does not transfer data in real time, it does overcome the drawbacks of real-time data transfer.
The batch process can be fine-tuned to only send user information which is either new or updated
Since this mode does not transfer data directly from your browser, it can be done over a secure network connection. This means you are free to transfer personal identity information.
For some real examples of how to implement batch data transfer to a DMP, please refer to the following integrations:
Combining Real-time and Batch Data Transfer
Since each mode of data transfer has different benefits, you may consider using both. You may transfer non-personal identity information (e.g., gender, age etc.) in real time. Then, you can use a batch process behind the scenes to transfer personal identity information.
Please create a test site in the Gigya admin console for integration testing (don't use your production site) and use a test list on the target integration platform. We are able to put integrations in "sample mode" for testing, which will restrict audiences to 10 sample accounts.
Accessing User Data
Access to user information requires that users login to the site through Gigya.
If you are implementing Social Login, then after the user logs-in the data available in the User object may be pushed to the DMP. This object, which is returned by the socialize.getUserInfo method contains social information pulled in from social networks.
If Gigya's Registration-as-a-Service (RaaS) package or Profile Management - IDS (IS) package is part of your site package, then the data returned by the accounts.getAccountInfo method may be pushed to the DMP. This includes social information pulled from social networks as well as site specific custom data.
To find out whether RaaS/IS package is part of your site package, or to activate RaaS/IS package, please contact your Gigya Account Manager or contact us by filling in a support form on our site.
Implementing Real Time Data Transfer
Real-time data transfer from Gigya to a DMP is implemented in three basic steps:
- Adding Gigya to web pages that use the DMP
- Handling browser events
- Passing non personal identity information to the DMP
These steps are demonstrated in the sample code at the end of this section
Adding Gigya to Web Pages that Use the DMP
GIgya's code is used to push logged in users' data to the DMP.
Gigya's User object can contain data from a number of different providers and does not record the source of each field's user data. It does, however, store the original data received from providers in Identity objects which are held within the User object. Gigya recommends that data passed to the DMP be taken directly from the Identity objects (rather than from the User object) because the data source is clearly identifiable. This makes it possible to securely comply with restrictions different social networks may have, and prevent data from specific social networks from being passed to DMP sites, or from being used to target ads outside the customer's own server. Identity objects hold data for a particular provider and make it possible to ignore data that originates from specific social networks (providers) and avoid non-targetable social network data. The sample code below demonstrates retrieval of Identity objects from a User object.
To use the code you must enter your Gigya API key and your DMP ID in the two src lines (src= etc.)
In addition you need to enter your DMP ID in the variable dmp-id and the DMP data type in the variable dmpDataType.
Handling Browser Events
When the user signs-in, the onLogin event returns the User object to the web page. User objects can also be retrieved using socialize.getUserInfo (not demonstrated in this example). Note that the data presented in the User Object directly represents an aggregated profile, and does not indicate from where the data originated. To provide data obtained from a specific provider, the user object contains an array of providers and an Identity object for each provider, with the provider's data for this user.
Filtering Out Personal Identity Information and Marking Non-targetable Data
Note that some identity providers do not allow their user data to be transferred to direct marketing providers, while others do not allow certain fields to be used in targeted advertising outside the customer's site. It is the customer's responsibility to comply with any such restrictions placed by each individual identity provider. The example below shows how this is done, for example, if you do not want to transfer LinkedIn data, or want to mark Facebook "age" data as non-targetable (even though you might use the age data for other purposes such as reporting). To achieve this, the onLogin event in the example calls the web-page's cbUserInfo function which extracts the identity object for each provider. LinkedIn data is ignored, and Facebook "age" data is marked as non-targetable. Other fields (or providers) can be added as required.
This example ignores LinkedIn data, and marks Facebook "age" data as non-targetable.
Implementing Batch Data Transfer
Batch data transfer is implemented using two basic steps
- User Matching
- Setting up batch data sync
The user matching process handles User ID reconciliation between your DMP and Gigya in real-time. The user matching code is to be implemented by the customer in the onLogin event, which returns the user's ID in Gigya.
Typically, your DMP will provide an API endpoint you can use to alert it of a Gigya GUID. When a user logs in, or a new user is created, you need to call this endpoint, allowing the DMP to match the user's Gigya GUID to its own UID table.
Setting Up Batch Data Sync
Batch data sync is done using Gigya's generic Data Extract procedures.