A useful demo allows you to follow the path from configuration to result. To evaluate app install attribution, the central question is whether the team can explain why a source was recognized and what happens when signals are missing.
Before running
Choose a platform and a limited scenario. Record the app version, channel, initial condition, and expected result. Agree how the first opening will be observed and where the identifying evidence will appear.
Also define which data can be used in the demonstration. If the example is synthetic, present this condition next to the result. A test with fictitious data explains how it works; does not represent a client case.
During the journey
Track the click, visit to the store, installation and opening, depending on the applicable scenario. Compare records with expectations. Include a trial without source information and check whether the result makes this absence understandable.
Don't hide a configuration error behind an end screen. Diagnosis and recovery are part of the experience that the team will operate.
After the result
Ask someone who did not conduct the demonstration to explain what was identified. Can this person repeat the test? Do you know how to locate a fault? Do you understand what remains unknown?
Record friction points and turn each into a verifiable documentation, example, or product improvement. This is an assessment script; not an account of pilots already run by Bridgee.
See the implementation guide and the paper evidence before the dashboard.