List attributes and table attributes: Use cases and features

Differences between list attributes and table attributes

The main difference between these features is where the conditions that constrain a visitor’s membership in an audience are defined. If you have defined your audiences in an external system and just want to target visitors who qualify for those audiences, use list attributes.  However, if you want to define your audiences in Optimizely Web Experimentation's audience builder using attributes that reside in an external system, use table attributes instead.

With list attributes, Optimizely Web Experimentation does not know anything about how you define your audiences. It receives a list of IDs for visitors who qualify for these audiences and instructions on where to check for a matching ID.

With table attributes, you can combine conditions that check the attributes' values together to create entirely new audiences that are not defined elsewhere. Because Optimizely Web Experimentation has direct access to these underlying values and the definitions of Optimizely Web Experimentation audiences, it can determine a visitor’s membership in the audience.

Another significant difference between list and table attributes is the way they handle updates. Uploading fresh data to an existing list overwrites the previous data contained in the list. Uploading fresh data to an existing table appends to previous data contained in the table. Only values for rows that existed in the table previously are overwritten. Any rows that are not present in the fresh data remain unchanged in the table (in other words, failing to provide values for a row will not delete the row).

This has implications for the most suitable use cases for each type of attribute:

• Lists are often better suited to integrations with other vendors, where it can be difficult to understand what has changed since the last time data was uploaded.  

• Tables are usually better suited to integrations with owned datasources, where it is easier to understand which records have changed since the last time data was uploaded.

Use case example

Suppose you want to target all users who belong to a particular list that you have defined in your email marketing platform. Users can qualify or disqualify for the list in real-time, and you can only see the current state of the list: you have no way of seeing past revisions or understanding which users may have been qualified for the list in the past but currently are not qualified. You upload data to Optimizely Web Experimentation once each day, and you want to make sure that only users who are currently in the email list are targeted.

In this case, list attributes are better because you only need to upload the current list. Optimizely Web Experimentation overwrites whatever data was uploaded previously, ensuring that users who no longer qualify for the list are not targeted. If you use a table attribute, you will have to keep track of which users were disqualified since the last update and explicitly overwrite your data.