Hallo Alex! To work with this is a nightmare. This needs a lot of processing power everywhere and the entire aMember Concept is based on this. I would really have prefered to see or design a seperate table for all the values stored in this field with an added possibility to have some dynamic information in the new table. Lets say a table amember_subscriptions could be designed. Then each plugin creates its own entries in that table. Everything becomes easier, visible, easy to handle etc. Here there is a huge bottle neck develop due to this field desgin. It not only creates nightmares in the import but also makes it supposedly the entire amember slow. This field always needs to be accessed for all reasons at all times. Thats the reason why I think it could be made it better in furture versions. At least if there is a small improvement of a new subscription table with basic data that would also help the speed of aMember.