HI
I'm developing Amplitude to AppsFlyer event streaming and I constantly get the message
"There was an issue with sending your test event. Invalid payload or configuration."
I tried different Map properties combinations, but I still get the response "Input has missing fields that the template expected: input.os_version".
Could you point out what I am doing wrong?
Thanks
Best answer by belinda.chiu
View original
+9
Thanks for reaching out here
Thanks for the reply. I've checked that thread, and unfortunately, it doesn't provide any options on how to fix my problem. I suppose the issue comes from a mapping mismatch, but there is no additional information on what needs to be changed.
In order for Amplitude to stream events into Appsflyer, each event needs to have an AppsFlyer ID. Can you please double check if the User ID you’re setting for your users on Amplitude matches your users’ AppsFlyer ID exactly?
Here’s the help doc with more details on how to set up this integration.
+8
+5
Update on the topic:
For the integration, error message on the Debugger tab says "message": "Input has missing fields that the template expected: input.os_version".
OS version is required by AppsFlyer. It is the os parameter in AppsFlyer. Send Event.
Hi, thanks for your help. I have added os parameter, but events are still missed in AppsFlyer.
Hi, Amplitude events are still missed on AppsFlyer. Would be glad for any update on my case! Thanks
+8
Hi
I took a quick peek at your data and it doesn’t seem like you have had any events where appsflyer_id is not none since you added the OS parameter (at least since the beginning of May). That might be why you aren’t seeing any events still since there aren’t events that fulfill the condition you set in your Appsflyer Event set-up.
+2
I’m seeing the same error, even when adding “OS”:
Input has missing fields that the template expected: input.os_version
+2
BTW, congrats to
🥳
When placing into the SAMPLE payload “os_version”: “iOS”, the error message goes away for the “Test Event” widget.
However, I don’t see how this is possible within the amplitude UI that we’re provided since os_version isn’t a mapped Appsflyer property. Do I need to create a completely new property “os_version” that is a duplicate of the existing “os” - that smells bad.
See below - “os_version” doesn’t appear as a selectable/mappable appsflyer property. My suggestion is that Amplitude adds that mappable Appsflyer property to the integration ASAP as that seems to be the reason why this is now broken. I believe this could have been caused by Appsflyer team suddenly requiring in the payload AFTER this integration was already released.
Another note: I’ve already filtered my events to make sure that I’m only sending iOS associated amplitude events to my iOS Appsflyer App. At first I thought that perhaps that was the issue - where the error message was missleading and that it was actually wanting to make sure that I wasn’t firing Android Events to an iOS Appsflyer App...
I’ve thought of another reason why this might not be working - the events I’m attempting to stream from Amplitude to Appsflyer are fired from the Back-End, NOT from the Front-End SDKs. Could it be that this streaming configuration isn’t expecting events fired from backend and thus is throwing some complaints about structure it’s used to seeing?
I’ve just confirmed that FE fired events are being streamed to AppsFlyer successfully.
I believe that the error message “Input has missing fields that the template expected: input.os_version” that we’re being shown is just a sliver of the actual problem: Events fired from our backend are not structured using the Amplitude FrontEnd-SDK, which automatically populates default fields.
The developers of this integration are expecting the additionally added event/user properties that the SDK provides. I’m would hazard a guess that this error is effecting anyone who is attempting to stream backend events OR who has turned off default tracking of User properties on their FrontEnd-SDK integration (See here: https://help.amplitude.com/hc/en-us/articles/115002380567-User-properties-and-event-properties ).
This could easily be fixed by the Amplitude identifying the TRUE list of required event/user properties and allowing the client (us) to map for them manually.
I’m going to have my team try and fire backend events with additional properties like “OS” and “Platform” that are usually added by the amplitude FrontEnd-SDK. I have a feeling that these will show up as “Custom” properties instead as “Amplitude native” properties - this could be another issue that needs addressing.
I don’t see why “os_version” would be a requirement from AppsFlyer - so I would also suggest investigating why this has been thrown in as an added hidden requirement for event streaming configuration to work.
In the meantime,
I would have assumed that the only required property would have been the custom added property “appsflyer_id”… but it seems that isn’t the way this was developed.
Or alternatively - Sharing a view of the source code for this streaming configuration, then I (or another engineer) could identify what exactly is going wrong and proceed (probably within a few minutes). - Just waiting for the amplitude team wander over to this issue and make some updates seems like it would take a bit too long😬
+2
Thanks
fwiw, the events I was trying to stream were from our front end Android SDK implementation, but I have also not yet integrated the appsflyer SDK, so there would not be a user id match on appsflyer’s side, which idk whether it’s required.
Hi
Thanks for your report here. The AppsFlyer OS field is required and we automatically map Amplitude OS version (os_version) to it. This does not need to be (and cannot be) selected as a mapping. If it does not exist on the event attempting to be sent, it will fail.
The default for the sample payload is static and will not necessarily work out of the box for the tester. You may need to add in required mappings or others fields. For AppsFlyer, os_version and an Amplitude field or user property corresponding to the AppsFlyer ID will need to be added to that payload for it to succeed. Even if the tester fails, this does not necessarily mean that there is an issue in the configuration.
The error shown in the screenshot is because os_version is missing from the payload. Same thing with the other similar error in a screenshot in the thread referring to user_properties.[AppsFlyer] appsflyer id; in user_properties they need to add "[AppsFlyer] appsflyer id": "some valid appsflyer id".
Currently, there is nothing required in the settings UI form to select anything for OS version. You’ll only need to make sure it is included on the events they are trying to stream, and that os_version is included in the tester payload. This is a mandatory requirement with AppsFlyer’s API.
We’re looking into making this clearer on our end as well as providing better instructions with the event tester, but hope this helps.
+2
Hi Jarren,
If I’m understanding, it sounds like you’re saying I should just ignore the test event failure message (that it’s buggy), since there’s nothing I can do to fix it, but also that os_version is mandatory in for the AppsFlyer API, meaning that Amplitude will be sending the os_version automatically for non-test events?
Hi
Thanks for your report here. The AppsFlyer OS field is required and we automatically map Amplitude OS version (os_version) to it. This does not need to be (and cannot be) selected as a mapping. If it does not exist on the event attempting to be sent, it will fail.
The default for the sample payload is static and will not necessarily work out of the box for the tester. You may need to add in required mappings or others fields. For AppsFlyer, os_version and an Amplitude field or user property corresponding to the AppsFlyer ID will need to be added to that payload for it to succeed. Even if the tester fails, this does not necessarily mean that there is an issue in the configuration.
The error shown in the screenshot is because os_version is missing from the payload. Same thing with the other similar error in a screenshot in the thread referring to user_properties.[AppsFlyer] appsflyer id; in user_properties they need to add "[AppsFlyer] appsflyer id": "some valid appsflyer id".
Currently, there is nothing required in the settings UI form to select anything for OS version. You’ll only need to make sure it is included on the events they are trying to stream, and that os_version is included in the tester payload. This is a mandatory requirement with AppsFlyer’s API.
We’re looking into making this clearer on our end as well as providing better instructions with the event tester, but hope this helps.
Thank you for that note - We’ve updated our backend events to include OS and found that SOME of the backend generated events are coming through as expected. Note that we are no longer getting errors in the debugger - However, not all of the events that should be streamed are getting sent. Our daily checksums of Amplitude VS Appsflyer are about 30% match for backend events (vs 100% match for FE events). We have looked into the events in question and can confirm via a filtered segment analysis in Appsflyer that “OS” and “Appsflyer ID” are being included in these backend payloads. What we find most confusing is that a portion of the backend events are coming through at all - we would think it would either be working or broken.
Have the Amplitude dev-teams tried to use this streaming integration with Async/Backend fired events before? Has this been tested? It seems like a major use-case across many industries, especially that of insurance and fintech where offline events like “money settling”, “application approved” etc are extremely common.
Our dev team had thought that this would be pretty straight forward, but it’s turning into a huge head scratcher. We would love to be able to share our analysis to Amplitude in the hopes that this powerful feature can be improved for all Amplitude Customers.
+8
Hi Jarren,
If I’m understanding, it sounds like you’re saying I should just ignore the test event failure message (that it’s buggy), since there’s nothing I can do to fix it, but also that os_version is mandatory in for the AppsFlyer API, meaning that Amplitude will be sending the os_version automatically for non-test events?
Hi
Correct, you can either ignore the test event failure message or add the parameters into the tester payload before hitting send. The error shown in the screenshot is because os_version is missing from the test event payload. Same thing with the other similar error in a screenshot in the thread referring to user_properties.[AppsFlyer] appsflyer id; in user_properties you will need to add "[AppsFlyer] appsflyer id": "some valid appsflyer id" to the test event payload.
To confirm again, there is nothing required in the settings UI form to select anything for OS version. You only need to make sure it is included on the events you are trying to stream, and to prevent the error from showing up, that os_version and other properties are included in the tester payload.
As for improvements to make this clearer, the Engineering team has in mind to have better defaults and clearer error messages for the tester, but they just haven’t been prioritized yet due to competing priorities. But they do plan to update our docs for this integration in the meantime to:
Make it clear that Amplitude OS Version is required.
Provide instructions on how to use the event tester, including exactly what must be added to the default payload to make it succeed for AppsFlyer (how to add os_version and the mapping/property for AppsFlyer ID).
Hi
Thanks for your report here. The AppsFlyer OS field is required and we automatically map Amplitude OS version (os_version) to it. This does not need to be (and cannot be) selected as a mapping. If it does not exist on the event attempting to be sent, it will fail.
The default for the sample payload is static and will not necessarily work out of the box for the tester. You may need to add in required mappings or others fields. For AppsFlyer, os_version and an Amplitude field or user property corresponding to the AppsFlyer ID will need to be added to that payload for it to succeed. Even if the tester fails, this does not necessarily mean that there is an issue in the configuration.
The error shown in the screenshot is because os_version is missing from the payload. Same thing with the other similar error in a screenshot in the thread referring to user_properties.[AppsFlyer] appsflyer id; in user_properties they need to add "[AppsFlyer] appsflyer id": "some valid appsflyer id".
Currently, there is nothing required in the settings UI form to select anything for OS version. You’ll only need to make sure it is included on the events they are trying to stream, and that os_version is included in the tester payload. This is a mandatory requirement with AppsFlyer’s API.
We’re looking into making this clearer on our end as well as providing better instructions with the event tester, but hope this helps.
Thank you for that note - We’ve updated our backend events to include OS and found that SOME of the backend generated events are coming through as expected. Note that we are no longer getting errors in the debugger - However, not all of the events that should be streamed are getting sent. Our daily checksums of Amplitude VS Appsflyer are about 30% match for backend events (vs 100% match for FE events). We have looked into the events in question and can confirm via a filtered segment analysis in Appsflyer that “OS” and “Appsflyer ID” are being included in these backend payloads. What we find most confusing is that a portion of the backend events are coming through at all - we would think it would either be working or broken.
Have the Amplitude dev-teams tried to use this streaming integration with Async/Backend fired events before? Has this been tested? It seems like a major use-case across many industries, especially that of insurance and fintech where offline events like “money settling”, “application approved” etc are extremely common.
Our dev team had thought that this would be pretty straight forward, but it’s turning into a huge head scratcher. We would love to be able to share our analysis to Amplitude in the hopes that this powerful feature can be improved for all Amplitude Customers.
One of our data scientists believes they found the discrepancy (after 2 weeks of head scratching).
Appsflyer organizes events NOT on the date the event was fired, but rather the date that the user was created. This makes sense since their focus is to see what events were associated to which cohort.
This means that when performing checksums for backend fired / offline events, if there is a significant amount of time in between the user being created and the backend event being fired, you will need to widen your search range significantly for Appsflyer to reflect that event being fired with said user.
We believe this means our backend events are fired properly and that this plugin does work for backend fired events - but the process of performing a checksum is a massive headache. We were able to 100% confirm by creating test BE events that fired immediately after a test user was created and confirming that they were coming through with a 1:1 match.
I’ll reach out to Appsflyer asking them to expose a “events fired” log (by event fired timestamp) in order to make this much less of a headache for other dev teams in the future.
If you don't have an Amplitude account, you can create an Amplitude Starter account for free and enjoy direct access to the Community via SSO. Create an Amplitude account. You can also create a Guest account below!
If you don't have an Amplitude account, you can create an Amplitude Starter account for free and enjoy direct access to the Community via SSO. Create an Amplitude account. Want to sign up as a guest? Create a Community account.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
