search

adobe / xdm

Experience Data Model
Creative Commons Attribution 4.0 International
245 stars 319 forks source link

Add Form based events and dimensions to ExperienceEvent #166

Open cdegroot-adobe opened 6 years ago

cdegroot-adobe commented 6 years ago

What are the schemas that are affected by the issue

https://github.com/adobe/xdm/blob/master/schemas/data/metrics.schema.json Some new way of representing standard Form dimensions.

What are examples of products that are impacted by the issue

AEM Forms -> the team contributing the information for the proposal.

Currently in use today:

Success Event Type
abandon Counter
render Counter
panelVisit Counter
fieldVisit Counter
save Counter
error Counter
help Counter
submit Counter

Dimensions: · formName: Identifier for an adaptive form. · formInstance: Identifier of an adaptive form instance. Enable Path reports for this variable. · fieldName: Identifier of an adaptive form field. Enable Path reports for this variable. · panelName: Identifier of an adaptive form panel. Enable Path reports for this variable. · formTitle: Title of the form. · fieldTitle: Title of the form field. · panelTitle: Title of the form panel. · analyticsVersion: Version of form analytics.

These are very standard concepts across many form implementations.

trieloff commented 6 years ago

Some of these sound like they are not only applicable to forms, but also to other transactions:

cdegroot-adobe commented 6 years ago

@trieloff - I want to pick this up again. The events would be in the context of 'form' which has a number of implications if that is the way we go. Assuming "https://ns.adobe.com/xdm/data/metrics/form/submit"

This would then add a a new context \form to the root of ExperienceEvents where we would contain data about the form in question, the dimensions in the OP and data or error messages/codes.

WDYT?

trieloff commented 6 years ago

@cdegroot-adobe I'm still a bit queasy about these buckets we introduce in ExperienceEvent, especially in cases where they are weakly defined and overlapping. It often feels like we are introducing them relatively ad-hoc, based on existing implementations or product boundaries rather than a unified concept.

See also: commerce/transaction, web info/web link (that was a mess – glad we fixed it), search engine/referrer

So 👍 to modeling it, but let's see if there are things inside the form bucket that could reasonably be generalized, and then do so.