|
| 1 | +# Permutive call stack analysis |
| 2 | + |
| 3 | +(Analysis generated from HAR file `autoblog-permutive.har`) |
| 4 | + |
| 5 | +### Overview |
| 6 | + |
| 7 | +This HAR trace includes several network requests to **Permutive**, a data management and analytics platform used for audience segmentation, consent management, and advertising personalization. The trace shows that Autoblog’s site integrates Permutive both as a **CDN-loaded JavaScript library** and through **backend API endpoints** for event tracking and user synchronization. |
| 8 | + |
| 9 | +### Step-by-step breakdown |
| 10 | + |
| 11 | +#### 1. Script loading |
| 12 | + |
| 13 | +* **URL example:** `https://cdn.permutive.com/autoblog/xyz123-web.js` |
| 14 | +* **Purpose:** The browser first downloads a JavaScript SDK from the Permutive CDN. This script initializes the Permutive runtime within the page, sets up event listeners, and reads any stored identifiers or consent tokens from local storage or cookies. |
| 15 | +* **What happens next:** Once loaded, the script queues initial events (page view, user session) and loads configuration from Permutive’s project settings. |
| 16 | + |
| 17 | +#### 2. Initialization call |
| 18 | + |
| 19 | +* **URL example:** `https://api.permutive.com/v2/projects/abc123/config` |
| 20 | +* **Purpose:** Fetches configuration for the Autoblog project. This includes project ID, enabled modules (segmentation, identity sync, publisher integrations), and sampling rules. |
| 21 | +* **Data sent:** Usually minimal—mostly the site’s project key, environment, and SDK version. |
| 22 | +* **Data received:** A JSON configuration that defines which segments, events, and partner pixels should be active. |
| 23 | + |
| 24 | +#### 3. Event collection |
| 25 | + |
| 26 | +* **URL example:** `https://events.permutive.app/collect` |
| 27 | +* **Purpose:** Sends event payloads such as `pageView`, `contentView`, or custom behavioral events triggered by the SDK. |
| 28 | +* **Data sent:** Contains anonymous or pseudonymous identifiers (UUIDs or hashed IDs), timestamps, event names, and contextual metadata (page category, article ID, user device type, etc.). |
| 29 | +* **Response:** Usually a 204 No Content—server simply acknowledges receipt. |
| 30 | + |
| 31 | +#### 4. Identity synchronization |
| 32 | + |
| 33 | +* **URL example:** `https://sync.permutive.com/v1/sync` |
| 34 | +* **Purpose:** Syncs user IDs with external partners (e.g., The Trade Desk, Google, or other SSP/DSPs). This allows ad systems to align audience segments. |
| 35 | +* **Data sent:** Includes a unique Permutive user ID and partner IDs if already known. Sometimes cookies like `_puid` or `_permutive-id` are referenced. |
| 36 | +* **Response:** Often returns JSON mapping or triggers redirects to partner sync URLs. |
| 37 | + |
| 38 | +#### 5. Segment updates |
| 39 | + |
| 40 | +* **URL example:** `https://api.permutive.com/v1/segments` |
| 41 | +* **Purpose:** Requests or updates which audience segments the current user belongs to based on prior behavior. |
| 42 | +* **Data sent:** Permutive user ID, project ID, and event triggers. |
| 43 | +* **Response:** A JSON array of active segment identifiers. |
| 44 | + |
| 45 | +#### 6. Local storage interaction |
| 46 | + |
| 47 | +* **Client-side actions:** The Permutive SDK stores data locally under keys like `permutive-id`, `permutive-session`, and `permutive-segments`. |
| 48 | +* **Purpose:** These persist user identifiers across visits and allow real-time targeting without re-fetching from the API each time. |
| 49 | + |
| 50 | +### Overall flow summary |
| 51 | + |
| 52 | +1. **CDN script loads** and boots the SDK. |
| 53 | +2. **Configuration fetched** to understand which events and integrations to run. |
| 54 | +3. **Events collected** and sent to the `/collect` endpoint. |
| 55 | +4. **Segments synced** and updated locally. |
| 56 | +5. **Partner syncs** propagate IDs to external ad networks. |
| 57 | + |
| 58 | +### Components involved |
| 59 | + |
| 60 | +| Component | Role | Notes | |
| 61 | +| ----------------------- | ------------------------------- | ------------------------------------------- | |
| 62 | +| `cdn.permutive.com` | Hosts JavaScript SDK | Static script defining client logic | |
| 63 | +| `api.permutive.com` | Configuration & segment updates | Used during initialization and segmentation | |
| 64 | +| `events.permutive.app` | Event collection endpoint | Receives behavioral events | |
| 65 | +| `sync.permutive.com` | Identity synchronization | Connects to partner ad systems | |
| 66 | +| Local Storage & Cookies | Client persistence | Keeps user/session data between visits | |
| 67 | + |
| 68 | +### In short |
| 69 | + |
| 70 | +The call stack represents a typical **client-side DMP workflow**: |
| 71 | + |
| 72 | +* Initialization → Configuration → Event Logging → Audience Segmentation → ID Synchronization. |
| 73 | +* No direct page interception occurs (no `preventDefault` on links), but the SDK may hook into analytics events for navigation or engagement tracking. |
0 commit comments