In this article:
In AudienceStream, we can only fire a connector when the user
There is no option available to fire a connector on any event while the visitor remains in an audience. This case arises where the user sends an event twice in a row and in the same visit and we want to trigger for both of them. This might happen online or, more commonly, through a File Import.
If this is not a concern, the Flip/Flop pattern discussed below is not needed and a single connector based on the above options will suffice. For tracking an event where you want to track a user that sends the same event twice there would need to be an intervening event to make the user leave the audience or the visit would need to end.
For some cases, EventStream would be the right answer here as long as the data you need is all present in the event. If we need to send Visitor/Visit level data, then the Flip/Flop patterns is one way to do this.
The Flip/Flop method works by having a Visitor Number attribute that follows the sequence 1, 2, 1, 2, 1.... (see below). You can then set up two equivalent audiences where the only difference is based on the value of that Visitor Number attribute. You are then guaranteed that on any incoming event that makes the user join or remain in the audience, the user will always join one of them (and leave the other one if they were already in it). You then need a pair of identical connector actions.
Create the Visitor Number attribute. In the example below we've titled this "Flip Flop [num]". Add an enrichment that increments this by 1 on any incoming event. Save the attribute. Then Edit and add a second enrichment, if the number is 3, set it back to 1. Once configured the value contained by this attribute follows sequence 1, 2, 1, 2, 1....
There is an edge case here if the event is one that stitches the user and causes a full event replay. This happens if this is not the first visit by both of the visitor profiles being stitched. In that case, it may end up that the visitor number remains at the same value it had before, and the connector would not re-trigger. Depending on your use case this may never be encountered.