How to send serialized events with processing rules

[jusaha]

Hi,

We have several numeric and currency events that we set from a context data value with processing rules. I would like to serialize these events with an ID that comes from our site.

However, according to the documentation context data can only contain alphanumeric characters, underscores and dots. But the serialized event requires a colon. So for example, it doesn't seem to be possible to send context data like this, and map it to a serialized event:

s.contextData['tp.volume'] = '3500:1253abc',
s.contextData['tp.units'] = '3:12345abc',

So how to send a serialized event with processing rules? I could send the value and ID as two separate context data, but concatenating values in processing rules seems to be only supported for eVars, not events.

[josh_donley · Accepted solution]

Context Data Variable names can only contain alphanumeric characters, underscores, and dots.  The values themselves can contain colons (and many other characters. See Illegal Javascript Characters for general limitations).

So for example,

Good:

s.contextData['tp.volume'] = '3500:1253abc',

Bad:

s.contextData['tp:volume'] = '3500:1253abc',

But as far as actually serializing an event via processing rule: I see what you are attempting to do, but I do not think this is possible. I could not find confirmation about it in the processing rule (or javascript) documentation, but I did find confirmation about it in the SDK documentation, and mobile services configuration ultimately creates regular processing rules.

[Andrew_Wathen_]

Out of the box you cannot serialize events using processing rules.  However....

If you've got a spare 'prop' and are prepared to pay Adobe Engineering to create a VISTA Rule for you, you can obtain the ability to control the serialize events through processing rules.  We have done this as we ran into the same problem with serializing events in our app.

Explanation of how the VISTA Rule would work...

First thing to know is that VISTA Rules cannot access context data variables (hence why you need to prop).

The second thing to know is that [normally] VISTA rules are after processing rules.

The basic premise is that you use processing rule to write into the prop, and prop is used to control what the VISTA rule does.

For instance:

You could set the vista rule up to look for values being passed in prop1 in a particular format e.g.

<event number>|<value>:<serialization number>

You could then use processing rules to write into prop1 the appropriate values...

e.g. event3|3500:1253abc

When the VISTA rule sees prop1 populated with a valid string it would set the event required with the appropriate value and serialization ID.  In this case event3 with a value of 3500 and a serialization ID of 1253abc

Hope this helps.

[josh_donley]

VISTA rule is a solution, but I recommend against it, unless you have no other alternatives and the business need is great enough to justify it.

1. VISTA rules are expensive. Like, thousands of dollars for even the smallest of things (like simple var dupe or rsid routing) expensive. In practice, approximately 99% of the time I have found it to be cheaper to put in the work for site code updates (in your case, updating s.events to include the serial id), than to go the VISTA rule route.
2. You have no visibility into VISTA rules to ensure on your end whether or not the logic is correct. So if you suspect things are not right, you have to contact engineering (which will cost you more money).
3. I have no idea the truth of this, but I heard a rumor Adobe is aiming to sunset VISTA rules, and will beef up Processing Rule capabilities.  So it is possible what you want to do will be available in PRs in the future.  But again, this is just a rumor I heard and I'm nobody important, so take it as a grain of salt.

So, before considering VISTA rule as a solution, I would recommend looking into what it would take you to just update your site code to send the events serialized in the s.events string.

Or, consider whether configuring your events in the interface to "Record Once Per Visit" is a "good enough" alternative. Or, consider setting an eVar to your serial id and set it to original value (or write logic to only set it once) and then use it as a breakdown or segment.  Neither of these alternatives are perfect, but they may be "good enough" for you, vs. committing to a VISTA rule.

[Andrew_Wathen_]

I would absolutely agree with this... unless you really need to be able to serialize in this way it's probably worth exploring other options.

But if you really need control serialization thru processing rules, the VISTA rule is probably the only way - be prepared to get your cheque book out :-)

[jusaha]

I have marked the original answer by joshd as correct, but the discussion has been really helpful, so thanks for that. Looks like I'll have to come up with a better way, given the downsides that have been pointed out about using VISTA rules.