Session Participation Payload

overview when a person participates with a session an sns message is published to a jomablue owned topic and the value of the sns ‘message’ will have the following structure this is published every time a person's attendance in a session is calculated and has a change this does not include 'session' resource, but the person to session participation (ie, session attendance) it's common for session names to change we recommend using id's over matching strings/session names attributes a description of each attribute in the session participation payload can be found below resource type string must be ‘session participation’ generated at timestamp timestamp in the following format 2025 07 02t19 15 12 511z context object event id string a unique identifier alphanumeric (upper and lower case), hyphens, forward slash and underscores no whitespace event name string alphanumeric (upper and lower case), special characters and whitespace event metadata object keys must only contain alphanumeric (upper and lower case), hyphens, forward slash and underscores no whitespace values can contain alphanumeric (upper and lower case), special characters and whitespace person first name string alphanumeric (upper and lower case), special characters and whitespace person last name string alphanumeric (upper and lower case), special characters and whitespace person email string a correctly formatted email address may contain an empty value person phone string alphanumeric (upper and lower case), special characters and whitespace may contain an empty value person company string alphanumeric (upper and lower case), special characters and whitespace may contain an empty value person id string a unique identifier alphanumeric (upper and lower case), hyphens, forward slash and underscores no whitespace person organisation uid string a unique identifier provided from external systems to jomablue (eg a salesforce lead/contact id) alphanumeric (upper and lower case), hyphens, forward slash and underscores session id string a unique identifier alphanumeric (upper and lower case), hyphens, forward slash and underscores no whitespace session name string alphanumeric (upper and lower case), special characters and whitespace may change through an event session organisaion uid string a unique identifier provided from external systems to jomablue (eg a salesforce campaign id) alphanumeric (upper and lower case), hyphens, forward slash and underscores identifiers object id string a unique identifier alphanumeric (upper and lower case), hyphens, forward slash and underscores no whitespace never empty data object attended boolean indicating if a person has attended the session or not updated at timestamp timestamp in the following format 2025 07 02t19 15 12 511z will match created at if not updates have been applied created at timestamp timestamp in the following format 2025 07 02t19 15 12 511z sample payload a sample of an session participation payload is below session participation { "resource type" "session participation", "generated at" "2025 01 28t04 27 07 322076z", "context" { "event id" "acme/event/123", "event name" "sonic conference 2025", "event metadata" { "text" "anything", "selector" "option2", "predefined" "predefinedvalue" }, "person first name" "catherine", "person last name" "lebsack", "person email" "catherine lebsack\@example com", "person phone" "+61491570006", "person company" "barrows, heaney and watsica", "person id" "acme/event person/123", "person organisation uid" "4ab9ecb4 91cd 34ba 928e b6d929b81a1c", "session id" "acme/session/123", "session name" "session of discovery", "session organisation uid" "ecb44ab9 91cd 34ba 928e b81a1cb6d929" }, "identifiers" { "id" "acme/session participation/123" }, "data" { "attended" true, "updated at" "2025 01 28t04 27 07 322076z", "created at" "2025 01 28t04 27 07 322076z" } } inferred sessions considerations this section describes inferred sessions and considerations around processing this data inferred sessions is an optional feature of jomablue that allows jomablue to infer someones attendance of a session based on the data we have available for a person along with parameters set by the event organiser traditionally (and if inferred sessions is not used), session attendance is obtained by scanning their badge on entry into the room this presents two challenges which inferred sessions solves back to back sessions when people stay in the room between sessions, the data point of the second session and beyond is never captured entering a session and changing their mind if a person enters a session then changes their mind within 5mins, the traditional approach would consider them as attended and therefor receive things like post event surveys for that session inferred sessions is an algorithm that addresses the two above points based on the data of that person and their interaction across the entire event additionally it offers a more streamlined onsite experience, attendees don't get the feeling of 'tracking' with so many points of data capture ability for event organisers to define what 'attended' is to them this is measured as a percentage over time to ensure that 15minute sessions and 60minute sessions can apply the same attended logic therefore as data is collect for each individual throughout the day, their attendance is calculated for each individual session this means that 'attendance' data is not necessarily tied to the physical action of them entering the room but a calculated output after that fact attendance data when inferred sessions is used, is usually calculated after the person enters the session room generally it's processed towards the end of the session or the end of back to back sessions unless other data is received sooner if inferred sessions is not used, the attendance is based only on entry to the session and does not require calculation these are generally published to sns immediately considerations we publish 'attendance' messages the moment we have enough data to calculate that and mark the person as attended (but that could be minutes or hours after they enter the session) an event organiser has flexibility to change the definition of 'attended' if that happens, we will re calculate the entire event and publish the changes this means that we may publish messages where the person is marked as not attended (after they were published as attended) offline mode may be used in events with poor connectivity, this may further delay the processing of session attendance