# Passing User Data to Gravity Field
**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.
## Front-end Data: dataLayer, objects on page, session, cookies, custom attributes
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.
{% hint style="warning" %}
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.
{% endhint %}
{% hint style="warning" %}
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.
{% endhint %}
Learn more about evaluators: [Evaluators](https://developer.gravityfield.ai/lang/en/general-information/evaluators)
Learn more about custom attributes: [Server-Side API](https://developer.gravityfield.ai/lang/en/server-side-api#choose-requesting-campaigns) or [Server-Side Hybrid](https://developer.gravityfield.ai/lang/en/hybrid-api#choose-requesting-campaigns) (Choose → Parameters) and [Targeting conditions definition and their applicability - Custom Attribute: API](https://developer.gravityfield.ai/lang/en/general-information/targeting-conditions-definition-and-their-applicability#custom-attribute-api)
## Events
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: [3. Events - Custom Event](https://developer.gravityfield.ai/lang/en/client-side-integration/3.-events#custom-event)
## Loading Data from CRM
{% hint style="info" %}
To load external data from CRM, you need to contact your Personalization Manager.
{% endhint %}
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](https://developer.gravityfield.ai/lang/en/implementation/full-data-loader-user-data-onboarding "mention")
## Conclusion and Comparison
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.
## Comparison Table
Page(frontend)
Custom Attributes (backend)
Frontend Events
Backend Events
CRM Data
Delay
High
Low
Average
Low
No delay
Requires user identification
No
No
No
No
Yes
Security of sensitive data
No
Yes
No
Yes
Yes
## Examples of User Parameters
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:
| Data Type | Example |
| ------------------------- | ------------------------------------------------------------------------------------------------------ |
| 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) |