When we send one-off emails from marketing cloud, JobID can be used to identify the email deployment as it is unique.
When it comes to journeys (in use-case where audience is entering the journey daily):
JobIDs for any triggered emails (including Journey Builder sends) persist until a publish event.
To answer you questions specifically:
Not necessarily
New JobIDs are assigned for sends after a publish event occurs on the send definition
It's no different than any other send
If you retrieve the aggregated Send SOAP object you can see the progression. Here's the script I use for doing that. You can use this data to join back to the
_Journeyand_JourneyActivitydata views to associate the sends to a specific journey.
Here's a query that illustrates the connection between the journey data and the send job:
Journey Jobs
select
j.jobid
, j.emailName
, jn.journeyName
, jn.versionNumber
from _Job j
inner join _JourneyActivity ja on ja.JourneyActivityObjectID = j.TriggererSendDefinitionObjectID
inner join _Journey jn on jn.VersionID = ja.VersionID
where 1=1
and convert(varchar(36),ja.JourneyActivityObjectID) != '00000000-0000-0000-0000-000000000000'
and isnull(ja.ActivityName,'') != ''
Adding to what Adam said.
no
The jobID is changed when you update to a new version.
Plus, it also changes when you save the email content within a running version, which works without version update. All you need to do is open the email content in the Journey Builder Email Activity, and hit "done", you do not even need to make actual changes. Once you see the screen that says something like "do not close this window", you get a new job Id. The notification is there because in the background, SFMC stops the triggered send, publishes changes, restarts. Next send from this journey will have a new jobid.
not sure what you want to understand here, skipping
jobId alone cannot do that, it is mutable. What I would do is custom track an ID that come up yourself, you enter to the relevant emails, and store it in a sendlog next to jobId / listid / batchid / subscriberkey. That way, you also have an immutable ID across email versions / content changes that relates to jobs and thus sends, opens , clicks etc.
