Integration QA Steps: Mobile Apps
Recommended steps to test your mobile app integration for accuracy.
Our Implementation Review lets Admin users view data snapshots from the latest full calendar day we have on hand.
Please note that a 5-10% difference between platforms is generally expected. If data is not coming through as expected, check out common issues in troubleshooting pageviews and unique discrepancies page
For details on general use of the dashboard please see our Implementation Review Introduction in our documentation
- 1.
- 2.Navigate to Settings from the menu top right-head
- 3.Implementation Review pages on the left side menu
- 4.Navigate to the Platform Audit and Traffic Audit Tabs
Tip: If you cannot access the Implementation Review, verify with your organization if your account has the required Admin role.
Once you're able to access the dashboard, here are some useful QA steps to ensure proper tracking:
- 1.Navigate to the Platform Audit Tab to view the Implementation Summary Table
- 2.Locate the "Mobile Apps" column and corresponding cell for the site and platform of interest
If there is a green checkmark in the corresponding cell, that means Chartbeat is receiving significant web traffic from the site at the time snapshot was taken.
- 1.Select a site and verify the timezone and snapshot date.
- 2.Summary table: reference Web pageviews breakdown to validate snapshot counts
- 3.Top Articles by pageviews: View the top 20 canonical paths and corresponding pageviews across all platforms
If data in the Implementation Review snapshots are as expected, your site is implemented correctly for this Mobile Apps. If more QA or troubleshooting is needed please continue with the additional QA steps below to assess your implementation.
When debug mode is enabled, exceptions will be thrown when the tracker is not started properly.
Note: When you are ready to submit the app for review, remember to disable debug mode.
For iOS, you can switch between logging tiers to see output from the tracker to help you with integration. There are four logging tiers:
- verbose: output everything
- debug: output debug related info, warning and error
- warning: output warnings and errors
- error: output errors (see property
loglevel)
All log output has the format
[CB]: xxxx[CBTracker sharedTracker].debugMode = true;
[CBTracker sharedTracker].logLevel = CBTrackerLogLevelVerbose;i
CBTracker.shared().debugMode = true
CBTracker.shared().logLevel = .verbose
Set
com.chartbeat.androidsdk.DEBUG to true before your first call to setupTracker.We recommend first adding our code in a test app, and using a corresponding test dashboard in your Chartbeat account to view the data before pushing your app to production with your prod site ID. For example, if your production site ID is
mysite.com, your test site ID could be test.mysite.app. In the following instruction articles for our Android and iOS SDK, remember when adding our code to your test app to use test site ID and update it to your production site ID only when your team is finished QA'ing the integration for data accuracy. Note: The test Site will need to be added to your organization's Chartbeat account to see your data in this sandbox dashboard. If you run into any issues adding this sandbox site to your account, contact your Chartbeat support representatives and we will add it for you.
Once you've added our code to your test app and added the test Site to your Chartbeat account, you can now watch real-time traffic data populate your test dashboard as your team interacts with different pages of your test app.
To view your test dashboard:
- 1.
- 2.From the Sites page, find your test Site and hover over the site entry to reveal the 'Real-Time' button.
- 3.Click the 'Real-Time' button.
Tip: If you do not have a Chartbeat user account, request access from one of your account admins.
- Requests to ping.chartbeat.net are made from all pages of the app where our SDK is implemented and the
trackViewfunction is called - Unique
viewId(page path) values are sent from every tracked view within your appviewIdvalues should be consistent for each unique screen across your iOS and Android apps, and you can check the value being sent to our servers in the "p=" parameter included in the outbound heartbeat requests to ping.chartbeat.netviewIdvalues should also match the canonical web URLs we receive from corresponding pages on your website if you intend to view app and web traffic data in the same dashboard- For views unique to the app without corresponding pages on your website, we recommend passing placeholder web URLs such as
https://www.mysite.com/app-homepage
- Each in-app page with a corresponding page on your website should also pass section, author, and title values which match exactly the sections, authors and titles we receive from the webpage
- For the Android SDK,
userInteractedcalls should be made each time a visitor touches the screen
Tip: For Android Oreo (8.0) and above, if you use Proguard for code optimization, a file has been added to our SDK library (version 1.6.6 and above) that should make Proguard builds including our library work automatically. If Proguard builds that include the Chartbeat SDK Library fail, the Proguard file can be added directly to your application’s Proguard rules.
In the Chartbeat requests to ping.chartbeat.net, the following query string parameters can be reviewed to see how data is being passed from each page via your team's code implementation:
QSP/Key | Description |
h | The domain (site ID) value set in your SDK implementation |
p | The viewId (page path) value your app is sending for the current view |
g0 | The section value(s) for the current view |
g1 | The author value(s) for the current view |
i | Page title for the current view |
E | Total engaged seconds so far for each page session |
The p, g0, g1 & i parameters should update with new values as you navigate to new views within the app, containing the unique page path, section, author, and title for each tracked view.
- Mobile App SDKs ✅
Last modified 1yr ago