How analytical subjects events are created from multiple sources

Hello,

I wanted to ask for more complex examples how mappings are working, if I have 5 sources used to populate one subject, how changes in the sources with different mappings (regular, auxiliary) will affect events created for this subject.

I would like to know how changes for subject not related to some process will affect the traversals function?

Best regards,
Jacek

Hey Jacek,

Lots to cover here, i’ll cover the main two directly, but you can also refer to our new documentation guide on this that just went live this week (good timing!):

Regular mappings are used when your source is considered “the truth” of which instances (the unique IDs loaded) need to exist in the subject. Unique IDs which are read and loaded from this source will persist into the final dataversion you see in the application. When loading a Subject analytic object, you should be mindful of ambiguous records in your files - if you have multiple records with the same subject ID and event date, only the last record with that combination will be loaded.

  • ie. if you’re loading the Employee subject, a source which lists all current active employees would be loaded with a Regular mapping. This source changing over time allows for the overall headcount to change with time.

Auxiliary mappings are used when you have additional information to augment the subject instances with and your source contains the same IDs as your regular sources. Think of it as a left join on the primary key in a database, this is visier’s equivalent.

  • ie. if you have performance rating data for employees, you don’t want this file to impact overall headcount - it’s just to add in some information. You can load this source as an auxiliary source, and only populate the properties necessary.
  • IDs that are loaded from an auxiliary mapping must match with an ID that also comes in from a regular source. If an ID is only ever loaded from auxiliary or lookup sources, it will be removed from the final data version.

If you’re loading an Event analytic object (ie. Employment Starts) then you only have access to the Regular mapping type. Events are generally loaded as “every record in the file will be loaded”, allowing multiple events to exist on the same date. This is different behaviour to how Subjects handle multiple records with the same date.

Hello, thanks for very detailed answer.

To be more precise, how mappings cause creation of change events for subject (not the analytical object events, but change events of the subjects.) In our case, we have this Applicant subject, we have no events defined for it, but there are change events created. So if we do “the left join” from data to aux mapping, we will create a new event for every changed row in the aux mapping data with given id and also if there is a change in regular mapping being the source, there will be record for that too?

Thanks in advance.

I am trying to understand, how change events/records are created here.

Ah - OK I understand what you’re wondering here.

Change events, or “profile change events”, are introduced to a data stream (we call this an “event stream” in visier) whenever a property/dimension for the individual changes, or is set for the first time when we read the source files during the data load process.

Change events are different than a “regular event” which is it’s own analytic object - the Event. Change events track how a property can change over time, ie. the Status/Stage of a requisition or applicant will go through changes over time.

Each mapping on a subject will create some change events. Generally, our mappings are efficient in that they will only insert a new change event when something actually changes, and this change will have an Event Date that aligns with what was read from the file (and whatever additional extraction logic may exist in the mapping for the event date property).

  • ie. if you provide a bunch of files where a property is the same value but with multiple different event dates, we will only extract that once on the earliest date found.

There are some properties like the Subject ID which get extracted multiple times especially when you have multiple mappings on same subject (ie. regular mapping, and some auxiliary mappings) but this is not a problem other than being slightly redundant - it’s just how the engine works.