Hi @roee_cachlon 

Thank you for reaching out about your Objects use case. Our team will reach out to speak more about this.

Beyond customer.io, this concept is something a lot of people struggle with in automation tools because custom objects are more complicated to manage. But IMO in most cases they make sense. 

The big question is this: “Would a contact and the object I want to create have a 1:1 relationship?”

1. If the answer is yes, the advantages of custom objects are limited, but still may be conceptually useful. 
2. If the answer is no, then custom objects are best

In your case, I don’t know if multiple contacts can be associated to the same subscription. Also, I would see the same user being associated to multiple subscriptions, for example if someone cancels, and then comes back, they likely have a new subscription and you don’t want to lose the history of the old one. 

If they can only every be associated to one subscription, there isn’t too much harm using properties, but honestly this is more rare than common. IMO based on your description, I would create a subscription object rather than creating contact level attributes.

Thanks for the detailed answer.

Can you give any examples for those 1:1 relationships?

Anyway, after more research we think that objects maybe the way to go, but now we have a different question - would you create different object for every plan duration (Object 1 = 1 month subscription with X $ price, object 2 = 6 months, y $ price, etc.) 

Or maybe create one object and 3 object attributes for each plan duration + 3 object attributes for each plan price?

Hope that’s makes sense.

@roee_cachlon trying to jump in, as I had a similar case with one of the products I use c.io for.

I assume that one person can just have one active subscription at a time, correct? Then, in my opinion custom objects are not the right thing to use in this case (or not really necessary). 

I am also assuming that you are selling a SaaS subscription, which has a backend who manages user login and also the purchase. It’s important that this is then the source of truth in terms of subscription of one user (purchase, type, renewal or new, cancellation).

In our case the backend sends those new_purchase/renewal/cancellation events to c.io, which then trigger different campaigns, depending on the type of subscription (as e.g. 1 year subscription has differently timed messages). The events should all contain the attributes you mention as payload. The campaigns can also write the values into more permanent attributes for better visibility of the current subscription and its status (and start/end date etc), probably as even the 1st “create or update person” action.

Does that make sense? Or are my assumptions wrong in the sense that you do not have a SaaS solution / backend which you can control and where you are able to set up those events sent to c.io tracking API?

@digitalisierungsprofi has an interesting point here. The third option is essentially forgo both of the ways you’re thinking and rely solely upon events. This works if the campaigns you’re currently thinking of running are based on points of time in the customer journey. Totally an option.

At some point you will want to segment customers based on their current subscription status, which I wouldn’t use events for. I also tend to avoid using events to update important attributes like subscription status. It can be overkill and that’s a lot of operational workflows to keep track of on your end. So for those I’d prefer and object sync. 

Ultimately though, there are many ways to accomplish the same thing!