Skip to main content
menu-icon.png

 

x
Optimizely Knowledge Base

List attributes vs table attributes: Use cases and features

 
relevant products:
  • Optimizely X Web Experimentation
  • Optimizely X Web Personalization

THIS ARTICLE WILL HELP YOU:
  • Understand the differences between list attributes and table attributes
  • Identify appropriate use-cases for each type of external attribute

List attributes and table attributes are the two types of external attributes currently supported by Optimizely. In general, you'd use a list attribute when you've already defined a group of users in an external system and want an easy way to target that audience with an experience, while a table attribute would be more appropriate when you want to target multiple audiences using a combination of attributes.

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.  Customers who have defined their audiences in an external system and simply want to target visitors who qualify for those audiences will likely use list attributes.  However, customers who want to define their audiences in Optimizely’s audience builder using attributes which reside in an external system will likely use table attributes.

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

But with table attributes, customers can combine conditions which check the attributes' values together, in order to create entirely new audiences which are not defined elsewhere. Because Optimizely has direct access to these underlying values and the definitions of Optimizely 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 will overwrite the previous data contained in the list. But uploading fresh data to an existing table will append to previous data contained in the table. Only values for rows which existed in the table previously will be overwritten. Any rows not present in the fresh data will remain unchanged in the table (in other words, failing to provide values for a given 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.

 

List Attributes

Table Attributes

Max file size

unlimited

unlimited

Max attributes per file

1

255

Key types supported

Cookie, query parameter, global JS variable, ZIP code

Cookie, query parameter, Global JS variable, Optimizely End User ID

Upload methods

Bulk: In-browser, Amazon S3, HTTP PATCH

Bulk: In-browser, Amazon S3

Single-record: HTTP POST

Update type

Replace (full list overwrite)

Upsert (insert new rows, update existing rows)

Supported campaign types

Experiments and personalization campaigns

Experiments and personalization campaigns

Use case example

A customer wants to target all users who belong to a particular list, which has been defined in their email marketing platform. Users can qualify or disqualify for the list in real-time, and the customer can only see the current state of the list: they have no way of seeing past revisions or understanding which users may have been qualified for the list in the past but are currently not qualified. The customer will upload data to Optimizely once daily, and they want to make sure that only users who are currently in the email list are targeted.

In this case, list attributes will be the better option, because the customer need only upload the current list and Optimizely will overwrite whatever data was uploaded previously, ensuring that users who no longer qualify for the list will not be targeted. If they were to use a table attribute, they would have to keep track of which users had been disqualified since the last update and explicitly overwrite their data.