Revenue analytics

[Blaumaus]

Summary by CodeRabbit

• New Features
  • Added getProfileId() and getSessionId() methods for retrieving profile and session identifiers. These new asynchronous APIs support revenue attribution and third-party payment processor integrations, returning null when identifiers are unavailable.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Two new asynchronous public methods, getProfileId() and getSessionId(), are added to both the Lib class and exported as public APIs in index.ts. These methods fetch profile and session IDs from the server via POST requests to /log/profile-id and /log/session-id endpoints, returning the corresponding string or null on error.

Changes

Cohort / File(s)

Change Summary

Profile and Session ID retrieval src/Lib.ts, src/index.ts

Added async getProfileId() and getSessionId() methods to the Lib class; both perform POST requests to fetch IDs from server endpoints, include conservative error handling, and respect profileId overrides. Exported equivalent public functions in index.ts that delegate to Lib instance methods, returning null if instance is uninitialized. Both include JSDoc comments with Paddle Checkout integration examples.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• Note: The diff indicates potential duplication of the added methods in src/Lib.ts; verify that duplicate blocks are not present in the final source file to avoid unintended method duplication.
• Confirm error handling paths are correctly returning null (not throwing) across both async methods.
• Validate that both src/Lib.ts and src/index.ts implementations are synchronized.

Possibly related PRs

• feat: Feature flags #23: Introduces or modifies profileId handling and getApiBase() resolution, which the new getProfileId()/getSessionId() methods depend on for API endpoint construction and ID override logic.

Poem

🐰 A pair of new methods hop into view,
Fetching profiles and sessions, shiny and new—
Through POST requests they bound and they leap,
Server responses their secrets to keep!
Thump, thump! goes the code, sleek and divine ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Revenue analytics' aligns with the main change: adding getProfileId() and getSessionId() methods for revenue attribution functionality, with documented integration examples for Paddle Checkout.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch revenue-analytics

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/Lib.ts (1)

619-696: Consider adding error logging and caching for better observability and performance.

Unlike getFeatureFlags() and getExperiments() which use console.warn for errors and cache results, these methods silently return null on failure and make a fresh network request on every call. Consider:

1. Adding console.warn for debugging when requests fail
2. Implementing optional caching if these methods are called frequently

🔎 Example with error logging

 async getProfileId(): Promise<string | null> {
   if (this.options?.profileId) {
     return this.options.profileId
   }

   if (!isInBrowser()) {
     return null
   }

   try {
     const apiBase = this.getApiBase()
     const response = await fetch(`${apiBase}/log/profile-id`, {
       method: 'POST',
       headers: {
         'Content-Type': 'application/json',
       },
       body: JSON.stringify({ pid: this.projectID }),
     })

     if (!response.ok) {
+      console.warn('[Swetrix] Failed to fetch profile ID:', response.status)
       return null
     }

     const data = (await response.json()) as { profileId: string | null }
     return data.profileId
-  } catch {
+  } catch (error) {
+    console.warn('[Swetrix] Error fetching profile ID:', error)
     return null
   }
 }

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d523fc9 and 9466f60.

📒 Files selected for processing (2)

• src/Lib.ts (1 hunks)
• src/index.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

src/Lib.ts (1)

src/utils.ts (1)

• isInBrowser (17-19)

src/index.ts (3)

src/Lib.ts (2)

• getProfileId (619-648)
• getSessionId (672-696)

dist/swetrix.es5.js (1)

• LIB_INSTANCE (314-314)

dist/esnext/index.js (2)

• LIB_INSTANCE (2-2)
• LIB_INSTANCE (2-2)

🔇 Additional comments (3)

src/index.ts (2)

266-293: LGTM! Well-documented public API for profile ID retrieval.

The implementation correctly validates LIB_INSTANCE and delegates to the instance method. The JSDoc includes helpful usage examples for revenue attribution scenarios.

---

295-321: LGTM! Well-documented public API for session ID retrieval.

The implementation correctly validates LIB_INSTANCE and delegates to the instance method. The JSDoc includes helpful usage examples for revenue attribution scenarios.

src/Lib.ts (1)

619-648: The code implementation is correct and well-documented with JSDoc examples. However, endpoint verification requires server-side testing, not codebase review—ensure the /log/profile-id and /log/session-id endpoints exist in your deployment and are documented in your server-side API specification.