Skip to content

feat: expose markAsClicked on InboxAction - #65

Merged
mikemilla merged 2 commits into
masterfrom
mike/action-click-tracking
Aug 28, 2026
Merged

feat: expose markAsClicked on InboxAction#65
mikemilla merged 2 commits into
masterfrom
mike/action-click-tracking

Conversation

@mikemilla

Copy link
Copy Markdown
Collaborator

What

An inbox action carries its own tracking id in data.trackingId, separate from the message's click tracking id. It lets a click be attributed to the button the user actually pressed rather than to the message as a whole.

Changes

  • InboxAction.markAsClicked(messageId), backed by the existing client.inbox.click, plus an InboxAction.trackingId getter.

An action from a template that opted out of tracking arrives without an id, so it is a no-op.

What this deliberately does not do

CourierInboxView renders through the native iOS and Android SDKs, and those report the action click themselves (Android already does; iOS is being added in trycourier/courier-ios#50). Reporting again from JS would count every press twice. What was missing here is only the API for apps that render their own action buttons.

Why this shape

Mirrors the convention already shipped in the Android SDK, where InboxAction.markAsClicked(messageId) reads data["trackingId"] and calls client.inbox.click. The same API is being added to iOS and Flutter, and the equivalent has landed in the web SDK.

Verification

tsc --noEmit clean for the changed file, and the repo's own eslint/prettier pre-commit hook passes.

🤖 Generated with Claude Code

mikemilla and others added 2 commits August 28, 2026 14:39
An action carries its own tracking id in `data.trackingId`, separate from the
message's click tracking id, so a click can be attributed to the button the user
actually pressed rather than to the message as a whole.

`CourierInboxView` renders through the native SDKs, which report the click
themselves, so this adds no reporting to the view — doing so would count each
press twice. What was missing is the API for apps that render their own action
buttons: `InboxAction.markAsClicked(messageId)`, backed by the existing
`client.inbox.click`. An action from a template that opted out of tracking
arrives without an id and is a no-op.

Mirrors the convention already in the Android SDK.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Cuts a patch release so the action click tracking in this branch ships.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
@mikemilla
mikemilla merged commit 46893b4 into master Aug 28, 2026
2 of 3 checks passed
mikemilla added a commit that referenced this pull request Aug 28, 2026
The API landed in #65, but that PR targeted `master` — a branch ~10 commits
behind `main` that the deploy workflow never publishes from. The change never
reached npm, and the 5.6.18 bump it carried belonged to master's old version
line. This puts the same code on `main` with a bump off 6.0.4.

An action carries its own tracking id in `data.trackingId`, separate from the
message's click tracking id, so a click can be attributed to the button the
user actually pressed. `CourierInboxView` renders through the native SDKs,
which report the click themselves, so nothing is added there — doing so would
count each press twice. This is the API for apps that render their own action
buttons. An action from a template that opted out of tracking arrives without
an id and is a no-op.

Also ships the Courier_iOS 5.8.6 podspec pin from #66, which merged after
6.0.4 was published and so has been sitting on `main` unreleased.

Co-authored-by: Claude Opus 5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant