All the macros should be blank, as in the following example:
#Link it testing install
Reset your device's attribution (see Resetting a Device and Clearing the Install Attribution).Ĭopy the tracking link again, but this time erase all the macro values, including the device ID.To test what happens when the tracking link is clicked from devices that don't supply the AIFA (GAID), do the following:
#Link it testing how to
Other Tests How to Test Probabilistic Attribution (Android Only) The Partner should be the partner you created the tracking link for. If your test install was attributed correctly, you will find a conversion event in the log with the Device ID of your device.
#Link it testing download
#Link it testing android
To find out the IDFA of your test device, you can download the Singular Device Assist app from the App Store.įor Android devices, you need the GAID (or AIFA). In the message box that appears, select Allow Apps to Continue Tracking.įor Apple devices, you need the IDFA identifier. Toggle off the Allow Apps to Request to Track option AND the Singular Device Assist app.
Then, reset your mobile device's advertising identifier according to the following instructions: Device Type If your mobile device has been used to test Singular attribution before, you have to clear the data.įirst, uninstall your app from the device. You have generated a new Singular Link using the Manage Links page.
The Singular SDK has been integrated into your app.ģ. Singular's attribution service has been set up for your organization.Ģ. You will be basically simulating an ad click and looking at Singular's attribution logs to check how the click was handled. Before you start using it in a campaign, you can test the link and see what information it sends to Singular. Now, instead of entering the site with our browser, we just make a request to check that the link is acutally live.You have just created a tracking link through the Manage Links page. You will still get a 200 or 404 status code, so the principle is exactly the same. The only difference is, that as a response, you usually get an html document, instead of json object. This might sound strange - why would you do an API request to a website? But http request is the exact same thing that your browser does when you type in a url. We can choose a different approach, and instead of opening our link using. Although our navigation bar might seem like it is working, it can in fact contain a broken link. Clicking on the about link will actually redirect us to a 404 page. We really don’t want to test too fast, because we might be missing an error.Īnd we are! Notice there’s not about page. Gleb Bahmutov has written a great blog on this topic. Although the main focus of our test is the navigation bar, we still want to see if the links open the correct page and we are not race conditioning. After the assertion on pathname passes, we go straight back. We are not waiting for our page to fully load. We’ll just add an item to the array and our test works.Īlthough made our test more DRY, there’s a slight problem with this. This is especially useful if for any reason our navigation bar changes items. In this test, we create an array (line 3) and then we create a forEach loop that will iterate through the array and repeats the action. It ( 'click all links with loop', ( ) => ` )
0 kommentar(er)
