Question Underscores added to event names breaking our analytics tracking

We pushed an update and noticed that suddenly all our custom events that we've already defined in UGS Analytics started getting the double underscores added to them and failing to import. I still see the custom events defined in UGS Analytics that should match what we're sending, but since the double underscores are getting added somewhere we're losing all our custom event data. What can we do to get it to stop adding double underscores?

We've defined events and their parameters and everything was working well for a while, and we haven't changed anything on our end so I can't see why it would have changed or what we can do on our end to get it working again.

We haven't updated Unity recently and we're pinned to 2020.3.36f1 at the moment. Analytics package is at 4.0.1.

Thanks!

 

I believe we've updated everything to use the new analytics. I do see both com.unity.analytics and com.unity.modules.unityanalytics in our manifest.json, but I checked our code and it only refers to the new analytics API.

Our project ID is e377fb33-0fa3-4fae-8257-9d176359d2ab and name is "Flipside", however I don't see where to find our organization ID.

 

The Campfire Union Inc. is the correct organization name.

It took me a while to find the legacy analytics toggle but just found it. I'll turn that off because I'm pretty sure we're not using legacy any more. I also cleared some outdated warnings and was able to fix a couple other events that were missing a parameter.

One of the last one's I'm seeing fail is a parameter that's the wrong type. The event name is "select_avatar" and the parameter in question is "avatar". What's weird is we're setting that parameter like this:

parameters["avatar"] = avatarId.ToString()

The error is that the value received looks like an int and the parameter type expects a string, but as you can see we should be sending a string already. And it looks like most of the time it's being received as a string.

A clue might be that the failed "select_avatar" event contents look quite different than the valid ones for the same event, but it doesn't look like anything we can change on our end.

Comparing that to the last failed events, which failed with a "Event timestamp outside valid boundaries - eventTimestamp" error, these also look quite different than the ones that passed. And most do seem to be passing. Since the event contents that differ don't seem like they're under our control, that may be a bug in the system, I'm not sure.

Anyway, thanks for the help and I hope the above is useful in figuring out if there are any edge cases where things might fail. Cheers!

 

I think we're all good from here.

That said, since some of the events that failed with the timestamp error were ones sent automatically by the library itself, that makes me think there might be a bug somewhere if it's able to create timestamps that are outside of those bounds.