Open dancingcactus opened 4 years ago
Any movement here? I am 100% blocked on Alloy migrations until some way to handle this is in place. Adding serialization for standard events was nice, but many organizations use it on custom events as well and there is no workaround available.
@jbradley-evo Apologies for the late response Jim. Let me track this down and get back to you shortly.
@jbradley-evo we are discussing internally. One question for you, are there other blocking things for you?
Hey Justin (aka @dancingcactus - one of these days I need to learn the genesis of that handle!)
I think the two other items we see as most needed (at least for one particular client) are the Redirect Tracking in A4T (although I keep discouraging redirect tests as much as possible) and Merchandising eVars on the product string. At least those two are in the In-Progress column.
Haha. Next time we are on a call I'll tell you the story. It isn't quite as exciting as it sounds.
This is super helpful. We are discussing internally on how to unblock you. We have a few ideas on the events thing and are really really close on the redirect tracking and merch evars and events (like a week or two).
Thanks for the update, Justin.
I can't imagine that the client I am working with on this are the only people waiting on event serialization. I know several of our clients use it although, to be completely honest, many do not.
Since Processing Rules do not support event serialization directly, does this mean it has never worked in apps? Or has someone come up with a workaround there?
Jim
On Thu, Jan 28, 2021 at 9:57 AM Justin Grover notifications@github.com wrote:
Haha. Next time we are on a call I'll tell you the story. It isn't quite as exciting as it sounds.
This is super helpful. We are discussing internally on how to unblock you. We have a few ideas on the events thing and are really really close on the redirect tracking and merch evars and events (like a week or two).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/adobe/alloy/issues/533#issuecomment-769184005, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL6UO3FDOLNBCVWSOBL7NBDS4GCOJANCNFSM4N72K3CA .
--
Jim Bradley | Evolytics http://www.evolytics.com/?utm_source=jim&utm_medium=em&utm_campaign=sig | Office: 816.778.7300 x221 | Cell 913.314.8200
Measuring Digital Marketing. Guiding Performance Optimization. Evolving Analytics.
Confidentiality Statement: This transmission is confidential and intended solely for the party to whom it is addressed. If the reader of this email is not the intended recipient, you are hereby notified that it may contain privileged, confidential and trade secret information, and that any dissemination, distribution, copying or use of the information in this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender at the email address above, and delete all copies of it from your computer.
@dancingcactus will then success events (e.g. event1) automatically be mapped into adobe analytics, without setting it by processing rules, like will there be a new xdm field to map success events in launch?
@vivasd to run this by Justing & Mitch.
This feature is complete but documentation has not yet been published. We will mark it as completed once the documentation is live.
This is vitally important as there is no way to do this in standard Processing Rules. Many existing Analytics implementations make use of this feature and an Alloy migration cannot be started until this is available.