From my understanding, the first "open" that's recorded for a particular JobId will have their IsUnique attribute as TRUE. Any subsequent opens AFTER that will still be recorded, but with IsUnique = FALSE.
However what I'm seeing here are two records, same JobId and SubscriberKey, different dates (about 9 days apart), both with IsUnique = TRUE. Not sure why this is?
Uniqueness in the events tables (click, open, sent etc data views) is established by the four IDs:
subscriberId (or key) => person
jobid => sendout
listId => which list is targeted (e.g. all subscribers list)
batchId => Sendouts are batched. If there is the same subscriber in the same job, the subscriber never goes into the same batch twice. This is meant to either allow duplicates in a bulk sendout (if the respective box is checked) or multiple iterations of the same subscriber receiving the same email through a triggered send or journey that is repeated. With your observed time gap, it looks a lot like the second case.
Some context: TS/ journeys "only" switch their jobids whenever the triggered send definition is restarted. Which for triggered send is an actual manual "stop/refresh/start", but in Journey builder of 2022, this also happens by changing journey version or when editing an email directly inside Journey Builder and hitting "done" (note you don't even have to make changes to the email - so actually, jobids could potentially change a lot, whenever this screen pops up:
This screen here occurs when you do that, and it tells you not to interrupt the "stop/refresh/start" pattern (which presumably is is still done in the background, but automatically -).
So: if a TS /journey is NOT changed, the same jobid would be still there after days or weeks, which looks exactly like what you are observing. The same subscriber just went into the journey again. You would be able to see a difference in their batchId.
