Passing User Data to Gravity Field
Last updated
Was this helpful?
Last updated
Was this helpful?
Created: 02.05.2023
Updated: 23.05.2023
Author: Polina A.
There are several methods of passing user data to the Gravity Field platform. In this article, we will comprehensively examine each of them, highlighting both their advantages and disadvantages.
All data available on the page can be utilized in GF using evaluators. With evaluators, this data can be used as targeting conditions for campaigns. Additionally, you can build audiences by passing front-end data to the platform using events sent through Custom Code, based on the data from these events.
Considering that data collection and transmission take time, a solution like this most likely won't allow using data on the first page load. In some cases, development team assistance may be required for configuration.
Personal information should never be transmitted this way. For server integration, custom attributes (`context.pageAttributes`) can be used as an alternative – in this case, execution delay significantly decreases, and data transmission is more secure.
Learn more about evaluators:
Learn more about custom attributes: or (Choose → Parameters) and
Events, just like page data, can be either frontend or server-side. In most cases, configuring them requires assistance from the development team. Server-server event transmission is a more secure method of sending sensitive data. In some cases, data may not be available on the first page load. The delay in transmission depends on the chosen method (frontend or backend) and when the data becomes available to the platform. Learn more:
In this case, data is loaded into the system using CSV files. The files contain information about user affiliation with specific segments (excluding personal data). With this information, audiences can be created for further use. The user ID (the same as in login and registration events) is used in the file as a unique identifier. To match a user with the information in the file, the user must identify at least once on the site after the file is loaded into the system. If the user is identified before the file was loaded into the system, an additional authentication is required to match the data.
Links: Full Data Loader — User Data Onboarding
In the case of using page data and events, the choice depends on when the necessary user information should appear during page loading. Both of these methods allow personalizing the user experience before user identification.
After identification, data loaded from CRM provides more opportunities for analytics and working with sensitive user information.
Loading data from CRM allows for the sending of data to the platform as a single block and seeing how many users meet specified conditions in real-time when creating an audience.
Thus, using page data or events is advantageous if you want to use existing data for targeting conditions, whereas loading data from CRM works better if you need to transmit sensitive information to the platform, build audiences for subsequent analytics and targeting, or for cross-session and cross-device targeting.
Delay
High
Low
Average
Low
No delay
Requires user identification
No
No
No
No
Yes
Security of sensitive data
No
Yes
No
Yes
Yes
A wide range of data can be used in the platform. We do not recommend passing personal data to the platform, but you can load any user information that helps in segmentation. This table can aid as a starting point:
Demographic
Gender, age group, marital status, children, pets, education level, income level
Geographic
Payment country/region, delivery country/region
Interests and Preferences
Favorite categories, preferred size, language
Customer Characteristics
VIP status, frequent shopper, loyalty program status, loyalty program points
Buying Habits
Average purchase amount, purchased items, days since the last purchase, average time between purchases
Internal Segmentation
App user, verified user (profile completion and status)