We do a lot of events across our global organization. It's, by far, the number one contributor to MQLs. As you know, there's often a manual element when working with event programs in Marketo - mainly, uploading the list of attendees post-event. Often times, that list isn't provided to our Marketo Ops team several days after the event. But for reporting and attribution purposes, this is causing issues for us since the attendance date stamp is the date that the leads' program status changes from "registered" to "attended" (essentially, the date that the list was uploaded). There's no way to edit this date to reflect the actual date.
If this is an issue for your organization - especially if you do a lot of events - it would be worthwhile to vote up this idea (especially since it's not currently on Marketo's roadmap (event though they "like it")).
I would imagine this could only be an issue if the Event was on March 31, and the upload date was on April 5, which could throw off things a bit.
Why not use the ipad connector to resolve most of this problem? Or have the event marketer do a daily upload?
At most firms, I don't see this ever being a problem.
Hi Josh - appreciate the response, but the mobile event app is far too limited for us to use at all events (we have used it at a couple events this year and doesn't allow/sync the required data that's needed in our programs). Lots of existing ideas around those limitations: . Also, several of the events/event attendees aren't using Marketo for registration - so all program membership is done manually.
As far as a daily upload, like I mentioned in my post, often times, the marketers don't get the complete list of attendees until several days after an event.
And you're correct, the majority of these issues are when the event takes place the last week of the month/quarter/year - the latter two are most critical.
In fact, this relates more globally to how Marketo manages program member information. Or more accurately, the total absence of it for the moment. We usually create additional fields and flow steps to mimic some of the functionality, but we are very far from what we should be able to do.
Agree, Greg - already voted up this one. You make a very good case for this.