Allan told you this from the very beginning - that you were probably sending progression events in Construct events that run on every tick. Then you posted a correct test project which got us puzzled.
You need to send progression only in triggered events (like "On click", "On touch", "On layout end" etc.), or in events that you definitely know will run only once.
Fair point, but remember: When Allan said it was working, I was still reading inflated data coming in on my GameAnalytics dashboard. Had I realized - then - that the GA log was in the console, I would have checked it at that point (chalk up a screwup for the noob).
I really didn't trust the code I first uploaded and still didn't trust it until now (more on that in a minute). Even though Allan had success with it, it generated excessive events for me, so far as I knew, I still had a problem at this end.
Granted, I should have looked for the logs instead of editing the project any further, but - hey, live and learn.
This said, I went back into the original test file just so I could be on the same page. Indeed, it shows perfect operation as per the Console. But if I'm reading the Console right, GA has held events from *previous* plays in its queue to send later:
If this is the case, I now understand why I though there was still a problem: Progression events from previous tests were stuck in the queue and being sent concurrent with the *properly coded* project sending accurate data.
At least this gives me an explanation why I thought there was a problem with the test project too. Until this moment, I was a bit puzzled myself.
Thanks again.
-Kurt
P.S.: It wasn't until after the first test project that I fell into the trap of experimenting using a system variable (an every tick event) as the event condition. I didn't realize these events required a System > Trigger Once condition as well to prevent them from running every tick. Otherwise, I usually don't make this mistake.