Important: If you are using Timestamps Optional, then do not sets.visitorID on data that is already timestamped. This can lead to out-of-order data and negatively impact time calculations (such as time spent values), attribution (eVar persistence), visit number/visit counts, and pathing reports.
Timestamps not allowed (setting s.visitorID supported)
Timestamps required (setting s.visitorID not supported)
Timestamps optional (setting s.visitorID supported but not on timestamped hits)
What is the reason for this limitation, and is it likely that this limitation will be addressed in the near future?
Does using s.visitorID on timestamped report suites force the processing to rely on hit_time_gmt rather than cust_hit_time_gmt? Depending on the answer, it may be worth it to have slightly out of order data, if it means we're able to see usage across multiple platforms by the same users.