Help Center

BlueConic collects a number of profile properties out-of-the-box, and this includes a set of properties that are read-only, meaning you can view but not modify the property settings. These properties are automatically added to new tenants, with each one having a specific data type.

There are currently five read-only properties generated by the system:

• Creation date: The date when the profile was created. (Data type is “Date time.”)
• Last visited date: The date when the person last visited your website. (Data type is “Date time.”)
• Domain group: The domain group that the profile belongs to. (Data type is “Text.”)
• Last modified date: The date when the profile last had a change. (Data type is “Date time.”)
• System has property: A list of all the properties that the profile has values for. (Data type is “Text.”)

These properties follow non-editable merge rules to ensure that no unexpected profile changes occur when a merge strategy is applied. For more details, review the Understanding the merge strategy section below.

Note: Sample ID is another system-created property, but this one is not read-only. Sample ID is calculated whenever two profiles are merged. Although you can update its property settings, you cannot apply a merge strategy to it, since it is never involved in the merging process.

Viewing read-only properties

Read-only properties automatically appear on the Profile Properties page (More... > Properties). To distinguish these properties from other properties on the page, they are listed in the table with a gray font color. Each one is clickable from the table and leads to the dedicated page for that property.

When you open one of these property pages, "Created by BlueConic" appears in the metadata section at the top, which indicates that it is system-created.

Tip: To review all system-created properties at once on the Profile Properties page, click Filters on the right, select Created by, and check the box for BlueConic.

Editing read-only properties

As stated earlier, you cannot modify read-only property settings; however, there are certain aspects of the property that are editable. On the property page, you can edit the name of the property at the top and the fields in the metadata section: Favorite, Labels, and Description. All other fields under "Settings" and "Expert settings" (with the exception of one) are grayed out and uneditable.

While each read-only property is set up differently, all six share these specific configurations:

• Available for segmentation: Yes
• Is unique identifier: No
• Data sensitivity: Non-PII
• Permission level: Level 1
• Merge strategy: System defined (as outlined below)

Note: Each read-only property has an ID that is hardcoded and separate from the editable property name; the system reads this ID to identify the data type for that property. The IDs for the five properties are listed below in italics:

• Creation date: creationdate
• Last visited date: lastvisit
• Domain group: domaingroup
• Last modified date: lastmodifieddate
• System has property: system_has_property

Segmentation

Under “Expert settings,” you can configure one setting at the bottom: “Hide from UI.” When this setting is enabled, the read-only property can be used for creating segments from server-side plugins but not from the Segments page. This setting differs from “Available for segmentation,” which is automatically enabled and makes the property available for creating segments in general.

Understanding the merge strategy

Read-only properties do not follow normal merge strategies. The merge strategy for these properties, which you cannot edit or alter, is defined by the platform and involves a "leading profile" that the other profiles get merged into. When a profile merge is enacted involving any of these properties, the system automatically determines which is the leading profile; the other profiles are then merged into that one profile—one at a time, property-by-property.

Once the merge is completed, only one profile remains: the “resulting profile.”

For the properties "Creation date," “Last visited date," and “Last modified date,” the value of the leading profile is always kept, since the leading profile already has each of these dates upon merging. This designated date is never altered, no matter what the dates are on the other profiles.

Since “Domain group” must be the same on all profiles for the merge to take place, that property isn’t merged. Likewise, "System has property" and “Sample ID” aren’t merged because they're not saved to the database; they're filled in after profiles are retrieved from the database.

Merging example

The following scenario illustrates how merging works with read-only profile properties. You notice that a man named Albert Apple has three separate profiles from visiting your website from three different devices: a desktop computer (A), a laptop (B), and a mobile phone (C). You want to merge all three profiles so that Albert has only one profile.

Before any merging begins, the system looks at the "Domain group" property and confirms it is the same on all profiles. Next, the system determines that the desktop computer (A) profile is the leading profile, so B and C are merged into A. First, B is merged into A; the read-only properties use the values of the A profile, while the other properties use the merge strategy defined on each property’s page (which may or may not result in altered values). Once the merge between A and B is complete, the B profile is deleted.

Next, C is merged into A in the same way, with the read-only properties using the values of the A profile. Once the merge is complete, the C profile is deleted, and the result is one profile with the correct values of all properties given the merge strategies they each had.