Fire after the commerce backend confirms order success — typically in the navigation-to-thank-you-screen handler. Don't pass the order ID, total, or line items. If you fire from your backend (more reliable for delayed-confirmation flows), use the same event_name.
▸Install the Swift (iOS) SDK
// Package.swift
dependencies: [
.package(url: "https://github.com/respectlytics/respectlytics-swift.git", from: "3.0.0")
]
// Or via Xcode → File → Add Packages → paste the URL above.The SDK ships only via Swift Package Manager. CocoaPods and Carthage are not published — fewer integration paths means fewer surfaces to keep audited.
▸Initialize Respectlytics in Swift (iOS)
import Respectlytics
@main
struct MyApp: App {
init() {
Respectlytics.configure(appKey: "<YOUR_APP_KEY>")
}
var body: some Scene { WindowGroup { ContentView() } }
}Call configure once at app launch — typically in your App struct's init. No Info.plist keys are required: the SDK does not call ATTrackingManager and does not request the IDFA, so NSUserTrackingUsageDescription should NOT be added.
▸Track the event in Swift (iOS)
import Respectlytics
func handleOrderConfirmation(_ confirmation: OrderConfirmation) {
// Backend has confirmed — fire the bottom-funnel event.
// No order ID, total, or items passed to analytics.
Respectlytics.track("checkout_complete")
showThankYouScreen()
}If you receive payment confirmation via Apple Pay's PKPaymentAuthorization Result, fire checkout_complete in the success callback rather than after a subsequent server round-trip.
✦Privacy & implementation notes
If you accept payments via Apple Pay, Google Pay, or 3D-Secure flows, the final order confirmation arrives server-side via webhook — sometimes seconds after the user has closed the app. Client-side checkout_complete will miss those. Server-side firing from your commerce-backend webhook handler produces a clean count.
Resist the urge to put order total into product analytics, even "for cohort analysis." Once revenue is in your analytics pipeline, every analyst will use it for something — and the lack of refund-aware mutation, currency conversion, and tax handling will silently corrupt every report. Keep revenue in commerce.
Apple rejected approximately 3% of apps in 2024 for incorrectly omitting NSUserTrackingUsageDescription when ATT was required by the SDKs they shipped. Respectlytics doesn't trigger ATT. The corollary is also true: do not add the key on Respectlytics's account — its presence implies you track across apps, even if your code never calls requestTrackingAuthorization.
Internally the Swift SDK uses Swift Concurrency: events are queued in an actor-isolated buffer (RAM-only), flushed on a 30-second timer and on UIApplication.willResignActiveNotification. Force-quit before flush drops queued events — by design. There is no UserDefaults or file backing.
⇋How this compares to other analytics SDKs
| Checkout complete event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Order ID stored | Yes | Yes | Rejected by API |
| Order total / line items | Yes | Yes | Rejected by API |
| Per-user revenue attribution | Yes | Yes | Use commerce backend |
| Conversion-rate by country / platform | Per-user | Per-user | Session-grouped |
| Refund / chargeback handling | Per-event mutation | Per-event mutation | Out of scope (use commerce backend) |
❓Frequently asked questions
How do we measure conversion rate without per-user attribution?
Per-session. The rate of sessions emitting checkout_complete divided by sessions emitting add_to_cart (or checkout_start) is the funnel rate. Country-bucketed and platform-bucketed gives you the segments. Per-user lifetime metrics live in your commerce backend, where they belong.
Where do we fire — client or server?
Server-side from the commerce backend's order-confirmation webhook is the most reliable path — client-side fires miss orders confirmed after the user closed the app. Use the Respectlytics REST API from your backend handler. Pick one; firing from both produces double counts.
Can we still compute average order value?
From your commerce backend, yes — that's where order totals live with authoritative timestamps and refund-aware totals. Respectlytics is the completion-rate signal; AOV is a commerce-backend signal.
What about repeat-buyer rate?
Out of scope for Respectlytics — it's an inherently per-user metric. Your commerce backend or customer-data platform has the customer history. Respectlytics tells you whether checkout is working; your CDP tells you who buys repeatedly.