docs(mobile-trackers): document manual screen-end triggering on iOS and Android [AISP-1670] - #1931
Merged
Matus Tomlein (matus-tomlein) merged 3 commits intoSep 4, 2026
Conversation
![snowplow-loop[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
|
Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign. Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks. |
Contributor
Missing SEO metadataThe following markdown files are missing required metadata fields:
Required fieldsThe file metadata is important for SEO and marketing. All markdown files, except for those with filenames starting with
Please add the missing metadata. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
documentation | 94e8721 | Commit Preview URL Branch Preview URL |
Sep 04 2026, 03:19 PM |
…implementation [AISP-1670] The original draft documented a proposed `EndScreenView` event with an optional `screenId` guard, written before the tracker implementations landed. The trackers ship something simpler, so this corrects the docs to match what integrators can actually call: - The event is the existing `ScreenEnd`, not a new `EndScreenView`. No new Iglu schema was needed — screen_end 1-0-0 already existed and is already modelled downstream. - There is no `screenId` parameter. The stale-call guard was never built, so the section documenting it is removed rather than describing an API that doesn't exist. - Ending a screen does NOT clear the Screen entity. The draft claimed it did; the trackers only transition that entity on the next ScreenView, and both tracker PRs pin this with tests. Also documents that manual and automatic screen ends don't double-count engagement time, and that the event isn't tracked when there's no active screen — both verified behaviours worth stating. Adds an iOS 6.3.0 version note. ScreenEnd was already public on Android. Verified with a full production build (link and anchor validation) and prettier --check. Refs snowplow/snowplow-ios-tracker#954, snowplow/snowplow-android-tracker#739 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Matus Tomlein (matus-tomlein)
marked this pull request as ready for review
September 4, 2026 15:08
Matus Tomlein (matus-tomlein)
requested review from
Peter Perlepes (igneel64)
and
a lite review from Copilot
September 4, 2026 15:08
Copilot started reviewing on behalf of
Matus Tomlein (matus-tomlein)
September 4, 2026 15:09
View session
Matus Tomlein (matus-tomlein)
approved these changes
Sep 4, 2026
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The new release note uses internal doc links that omit /index.md, which conflicts with the repository’s internal-link convention and should be corrected before merging.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR documents how to manually trigger ScreenEnd on the iOS and Android mobile trackers, aligning the docs with the shipped tracker behavior, and adds a companion release note announcing iOS ScreenEnd API availability.
Changes:
- Add a “Manually ending a screen” section with iOS/Android code examples and behavioral notes (engagement summary ends;
Screenentity persists until the nextScreenView). - Add a release note announcing iOS tracker 6.3.0 making
ScreenEndpublic and explaining when manualScreenEndis useful.
File summaries
| File | Description |
|---|---|
| release-notes/manually-ending-screen-tracking-on-ios-and-android/index.md | Adds a release note describing manual ScreenEnd usage and linking to the detailed tracker docs. |
| docs/sources/mobile-trackers/tracking-events/screen-tracking/index.md | Adds documentation and examples for manually ending the active screen without starting a new screen view. |
Review details
Suppressed comments (1)
release-notes/manually-ending-screen-tracking-on-ios-and-android/index.md:16
- Internal doc links should include
/index.mdbefore the anchor so they validate consistently and don’t rely on directory routing/redirects.
See [manually ending a screen](/docs/sources/mobile-trackers/tracking-events/screen-tracking/#manually-ending-a-screen) for details and code examples.
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| --- | ||
| The iOS tracker version 6.3.0 makes the `ScreenEnd` event public, so you can manually end the currently active screen. The event has always been public on the Android tracker. | ||
|
|
||
| Automatic screen view tracking doesn't always produce a `screen_end` event when the user actually leaves a screen. This happens, for example, when a WebView is presented on top of a native screen and a page view tracked from the WebView doesn't end the underlying native screen, so [screen engagement metrics](/docs/events/ootb-data/page-activity-tracking/#screen-engagement) keep accumulating against a screen that's no longer visible. The same gap appears on screens built with Jetpack Compose or SwiftUI that aren't covered by automatic screen view tracking. |
…AISP-1670] The section opened with "automatic screen view tracking doesn't always produce a screen_end event", which assumes the reader already knows it normally does. That fact was only stated 190 lines earlier, as one item in a list about the screen_summary entity, so anyone arriving from search or the sidebar could reasonably conclude ScreenEnd is a manual-only event and start tracking it after every screen. Now states up front that the tracker ends screens automatically before each screen view and that you don't normally need to do anything, then gives the case that isn't covered. Also drops the Jetpack Compose / SwiftUI example. A partially instrumented screen is better fixed by instrumenting its screen view than by manually ending the previous one, so pointing at ScreenEnd there would be steering people to the wrong tool. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Matus Tomlein (matus-tomlein)
deleted the
loop/jira-AISP-1670-documentation
branch
September 4, 2026 16:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents how to manually end a screen on the iOS and Android trackers, in
docs/sources/mobile-trackers/tracking-events/screen-tracking/index.md, plus an accompanying release note.Why
The tracker already tracks a
screen_endevent automatically before each new screen view, which covers screen-to-screen navigation. It doesn't cover a user leaving a screen without a new screen view being tracked — most notably when a WebView using the JavaScript tracker is presented over a native screen. Apage_viewfrom the WebView doesn't end the underlying native screen, so itsscreen_summarykeeps accumulating engagement time against a screen nobody is looking at.What the docs say
The section leads with the automatic behaviour — you don't normally need to end a screen yourself — and then covers the case that isn't handled:
Also documented:
ScreenViewreports only the time elapsed since the manual call, so engagement time is never counted twice.Screenentity. Events tracked afterwards still carry the ended screen until the nextScreenView— the same way they do while the app is backgrounded.previous_*on the next screen view references the ended screen.ScreenViewhas been tracked,ScreenEndisn't tracked at all.No new Iglu schema is involved:
screen_end1-0-0 already exists and is already modelled by the Unified dbt package, because the automatic path emits it today.Versions
Added an iOS 6.3.0 note.
ScreenEndhas always been public on the Android tracker, so no Android release is required.Companion PRs
ScreenEndpublic on iOSBoth behaviours called out above (no double-counting, entity survives the end) are covered by tests in those PRs.
Verification
yarn build) passes — validates every link and anchor, including the cross-page references in the new section.prettier --checkpasses on both changed files.Refs AISP-1670, BCPF-2066.