Storage value for lists subscriptions

Splio offers up to 64 lists for subscriptions, meaning that a contact could be a subscriber of one list, several lists, or no list (in the latter the contact wouldn't be contactable).

Lists must be considered as subscriptions, to let for instance an individual subscribe to a Perfume-oriented newsletter, and/or a Shoes-oriented one.

Lists should not be used as temporary storage (temporary files are the way to go), or for segmenting a database (filters are the way to go).

Knowing that, 64 is a high number of lists, and most of the case you'll only need a few.

The reason the limit is 64 is due to the fact that systems nowadays relies on 64-bits architecture CPUs, and that Splio stores the list subscriptions of each contact in an optimized (although imaginative) way: by translating list IDs into binary bits, stored in decimal.

Here's an example:

In this example, there are only 4 bits, so we're limited to 4 lists, but there are 16 possible combinations, from 0 to 15 in decimal value.

With 64 bits, there are 18 446 744 073 709 551 616 possible combinations (you already know it, but that's more than 18 quintillions)

Nice. Why is this important?

The value stored for each contact's subscriptions is therefore a non-negative decimal value, and potentially huge.

That also means that when downloading contacts from Splio, you'll get that non-negative potentially huge decimal number as well, and if you plan to re-import the contacts later one, you'll have to make sure to not alter the subscriptions value. Excel can be a good candidate to altering it, as it would try to shorten it into "1,84467E+19". If you re-import this, it's not going to work well.

Also, the importing feature of the platform is expecting a proper number if you intend to use the "membership" field in the mapping stage of the import, but when preparing a file to be imported with Datahub, the field "subscriptions" expects a totally different value.