Events API

עקבו אחרי אירועי משתמשים והתנהגות באופן תכנותי באמצעות REST API.

כל נקודות הקצה בעמוד זה יחסיות לכתובת הבסיס: https://api-eu1.joryio.com/api - ראו סקירת API.

אימות

כל הבקשות דורשות אימות עם מפתח API:

Authorization: Bearer jry_live_your_api_key_here
Content-Type: application/json

אירוע הרכישה

דיווח הכנסות, שיוך, CLV והמודלים החזויים - כולם קוראים אירוע אחד. אם תשלחו רכישות בשם אחר, הן לא ייספרו - בשום מקום.


שם האירוע	`Order Completed`
מאפיינים נדרשים	`total`, `currency`
מומלץ	`total_base`, `base_currency`, `orderId`

{
  "eventName": "Order Completed",
  "userId": "user_123",
  "properties": {
    "total": 149.90,
    "currency": "EUR",
    "total_base": 162.35,
    "base_currency": "USD",
    "orderId": "1024"
  }
}

למה רק שם אחד

פלטפורמות אחרות משתמשות בשמות אחרים - Placed Order, purchase (GA4). אנחנו בכוונה לא מקבלים אותם, כי קבלה של כמה שמות משמעותה חיבור שלהם: חנות שמריצה תגית GA4 לצד המחבר שלנו תשלח מכירה אחת בשני שמות ותראה הכנסה כפולה. מספר הכנסות שגוי בשקט פי 2 קשה הרבה יותר לזהות ממספר שהוא בבירור 0.

לכן הכלל הוא חוזה אחד מפורסם. אם ההזמנות שלכם לא מופיעות, הסיבה גלויה מיד בהטמעה - וניתנת לתיקון - במקום להיות שגויה בשקט במשך חודשים.

על הסכומים

total ו-total_base הם שני נתונים שונים, לא חלופות:

total - מה שהלקוח שילם, במטבע שבו שילם (presentment).
total_base + base_currency - אותה הזמנה מומרת למטבע הדיווח שלכם. שלחו אותם אם אתם מוכרים ביותר ממטבע אחד, כדי שסכומים בין מטבעות יתחברו נכון.

אם יש לכם מטבע אחד בלבד, שלחו total בלבד. orderId הוא אופציונלי אך מומלץ: הוא מונע כפילות של הזמנה שמגיעה יותר מפעם אחת (ניסיון חוזר, רענון עמוד בתשלום).

אם אתם כבר שולחים שם אחר

האירועים ההיסטוריים שלכם נשמרים, אך אינם נחשבים הזמנות. העבירו הזמנות חדשות ל-Order Completed, ודיווח ההכנסות יתחיל מאותה נקודה. איננו משכתבים אירועי עבר, כך ששום דבר לא מתפרש מחדש בשקט מתחתיכם.

קודי קופון באירוע

כשההזמנה מגיעה מחנות מחוברת או מ-Orders API, Order Completed כולל גם:

מאפיין	סוג	תיאור
`coupon_codes`	string[]	כל קודי הקופון בהזמנה, באותיות קטנות (`["summer10", "vip"]`); `[]` כשאין
`coupon_count`	number	כמה קודים שימשו בהזמנה

מסע יכול להתחיל ב-Order Completed כאשר coupon_codes מכיל summer10 - ההתאמה אינה תלויה באותיות גדולות או קטנות ובודקת כל קוד.

חנות וערוץ מכירה באירוע

האירועים Order Completed, Order Refunded ו-Order Cancelled כוללים איפה נמכרה ההזמנה ואת החנות שלה:

מאפיין	סוג	תיאור
`sales_channel`	string	`online`, `pos`, `app`, `phone`, `marketplace` או `other` - קיים תמיד
`store_id`	string	החנות שאליה שייכת ההזמנה (המזהה של חנות מחוברת, או ה-`storeId` שהזמנת ה-API שלכם שלחה) - רק כשיש כזו

אפליקציה יכולה לשלוח אותם ב-Order Completed משלה: sales_channel (מתקבל גם כ-salesChannel; ערך שלא ברשימה נשמר כ-other), store_id ו-store_name. בלי sales_channel, הזמנה שנרשמה מאפליקציית iOS או Android מקבלת app והזמנה מאתר מקבלת online. מסע יכול להתחיל ב-Order Completed כאשר sales_channel הוא pos. ראו חנות וערוץ מכירה.

שליחת אירועים

אירועים נקלטים דרך POST /users/track, שמקבל מאפיינים, אירועים ורכישות בקריאה אחת.

curl -X POST https://api-eu1.joryio.com/api/users/track \
  -H "Authorization: Bearer jry_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "events": {
      "externalId": "user_123",
      "name": "Product Viewed",
      "properties": { "productId": "SKU-456", "price": 49.99 }
    }
  }'

events מקבל אובייקט בודד או מערך של עד 500. ראו Track למפרט השדות המלא, כללי הזהות וצורת התגובה.

Order Completed אינו נשלח כאירוע

הוא נפלט אוטומטית מרכישה. שלחו רכישות במערך purchases במקום - ראו אירוע הרכישה למעלה כדי להבין למה שליחה ידנית שלו או רושמת הכנסה בלי הזמנה מאחוריה, או סופרת את המכירה פעמיים.

Query Events

שליפת אירועים עם סינון ועימוד. אין נקודת קצה לשליפת אירוע לפי מזהה - סננו את השאילתה הזו במקום.

Endpoint

GET /events/query

פרמטרי שאילתה

פרמטר	סוג	ברירת מחדל	תיאור
`userId`	string	-	סינון לפי מזהה משתמש
`eventName`	string	-	סינון לפי שם אירוע
`startDate`	string	-	אירועים לאחר תאריך זה (ISO 8601)
`endDate`	string	-	אירועים לפני תאריך זה (ISO 8601)
`limit`	number	100	תוצאות לעמוד (לכל היותר 1000)
`offset`	number	0	מספר אירועים לדילוג

דוגמת בקשה

# Get all "Order Completed" events in January 2024
curl -X GET "https://api-eu1.joryio.com/api/events/query?eventName=Order+Completed&startDate=2024-01-01T00:00:00Z&endDate=2024-02-01T00:00:00Z&limit=100" \
  -H "Authorization: Bearer jry_live_your_api_key"

תגובה

מערך JSON חשוף, מהחדש לישן. שדות האירוע ב־snake_case (הם מגיעים ממחסן האנליטיקה):

[
  {
    "event_id": "9b2f6c1e-4a8d-4f0b-9c3d-2e1f5a6b7c8d",
    "user_id": "665f1e2a9b3c4d5e6f7a8b9c",
    "anonymous_id": "",
    "event_name": "Order Completed",
    "properties": {
      "orderId": "order_456",
      "total": 99.99
    },
    "timestamp": "2024-01-20 14:30:00",
    "session_id": "",
    "device_id": ""
  },
  {
    "event_id": "1c3e5a7b-9d2f-4b6c-8e0a-3f5d7b9c1e2a",
    "user_id": "665f1e2a9b3c4d5e6f7a8b9d",
    "anonymous_id": "",
    "event_name": "Order Completed",
    "properties": {
      "orderId": "order_789",
      "total": 149.99
    },
    "timestamp": "2024-01-19 10:15:00",
    "session_id": "",
    "device_id": ""
  }
]

Event Aggregation

קבלת סטטיסטיקות אירועים מצטברות עם קיבוץ ומדדים.

Endpoint

POST /events/aggregate

גוף בקשה

שדה	סוג	חובה	תיאור
`eventName`	string	כן	שם האירוע לסיכום
`startDate`	string	לא	תאריך התחלה (ISO 8601)
`endDate`	string	לא	תאריך סיום (ISO 8601)
`groupBy`	string	לא	קיבוץ זמן: `hour`, `day`, `week`, `month` (ברירת מחדל: `day`)
`metrics`	array	לא	מדדים לחישוב: `count`, `sum`, `avg`, `min`, `max` (ברירת מחדל: `['count']`)
`sumField`	string	מותנה	שם המפתח בתוך `properties` לחישוב סכום/צבירה (למשל `total`). חובה כאשר `metrics` כולל `sum`, `min` או `max`
`avgField`	string	מותנה	שם המפתח בתוך `properties` לחישוב ממוצע. חובה כאשר `metrics` כולל `avg`

מדד ללא שדה נדחה

שם מדד לא מוכר, או מדד שחסר לו השדה שלו (sum ללא sumField), מחזיר 400. בעבר שניהם החזירו 200 כשהמדד פשוט נעדר מהתוצאה - דבר שלא ניתן להבחין בינו לבין אפס אמיתי.

דוגמת בקשה

curl -X POST https://api-eu1.joryio.com/api/events/aggregate \
  -H "Authorization: Bearer jry_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "eventName": "Order Completed",
    "startDate": "2024-01-01T00:00:00Z",
    "endDate": "2024-02-01T00:00:00Z",
    "groupBy": "day",
    "metrics": ["count", "sum"],
    "sumField": "total"
  }'

תגובה

{
  "success": true,
  "data": {
    "eventName": "Order Completed",
    "groupBy": "day",
    "metrics": ["count", "sum"],
    "results": [
      {
        "period": "2024-01-01T00:00:00Z",
        "count": 45,
        "sum_value": 4567.89
      },
      {
        "period": "2024-01-02T00:00:00Z",
        "count": 52,
        "sum_value": 5123.45
      },
      {
        "period": "2024-01-03T00:00:00Z",
        "count": 38,
        "sum_value": 3890.12
      }
    ],
    "total": 3
  }
}

מדדים נתמכים

count: מספר האירועים הכולל
sum: סכום ערכי השדה שצוין
avg: ממוצע ערכי השדה שצוין
min: הערך המינימלי של השדה שצוין
max: הערך המקסימלי של השדה שצוין

דוגמה: ניתוח הכנסות

# Get daily revenue from purchases
curl -X POST https://api-eu1.joryio.com/api/events/aggregate \
  -H "Authorization: Bearer jry_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "eventName": "Order Completed",
    "startDate": "2024-01-01T00:00:00Z",
    "endDate": "2024-01-31T00:00:00Z",
    "groupBy": "day",
    "metrics": ["count", "sum", "avg"],
    "sumField": "total"
  }'

דוגמה: שימוש ביכולת לפי שעה

# Track feature usage patterns by hour
curl -X POST https://api-eu1.joryio.com/api/events/aggregate \
  -H "Authorization: Bearer jry_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "eventName": "Feature Used",
    "startDate": "2024-01-20T00:00:00Z",
    "endDate": "2024-01-21T00:00:00Z",
    "groupBy": "hour",
    "metrics": ["count"]
  }'

גילוי מה מרחב העבודה שולח

לפני שבונים מול האירועים של מרחב עבודה, שאלו אותו מה הוא באמת מקבל. ארבעת המסלולים האלה הם הדרך שבה אינטגרציה מגלה במקום לנחש.

שמות אירועים

GET /events/names

כל שם אירוע שנראה במרחב העבודה הזה, כמערך JSON חשוף ממוין לפי א-ב. זה אוצר המילים האמיתי, לא זה שמישהו התכוון אליו.

תגובה:

["Order Completed", "Page Viewed", "Product Viewed"]

סטטיסטיקת אירועים

GET /events/stats?startDate=2026-08-20T00:00:00Z&endDate=2026-08-27T00:00:00Z

נפח לכל אירוע לאורך חלון זמן - הדרך המהירה ביותר לוודא שאינטגרציה עדיין מספקת נתונים, ולשים לב כשאחת הפסיקה בשקט. startDate ו-endDate הם חותמות זמן ISO 8601 אופציונליות (אין פרמטר days); בלעדיהם נספרת כל ההיסטוריה.

תגובה - מערך JSON, האירועים העמוסים ביותר תחילה, עד 1,000 שורות. count הוא אירועים ייחודיים, unique_users אנשים ייחודיים:

[
  { "event_name": "Page Viewed", "count": 1204331, "unique_users": 88012 },
  { "event_name": "Order Completed", "count": 48210, "unique_users": 31877 }
]

סכימות אירועים

GET /events/schema?limit=50&offset=0
GET /events/schema/Order%20Completed

מסלול הרשימה מדפדף בכל אירוע שמרחב העבודה קיבל (limit ברירת מחדל 50, לכל היותר 1000; offset ברירת מחדל 0) עם ספירות אך בלי מאפיינים. מסלול האירוע הבודד מקבל את שם האירוע בנתיב, בקידוד URL - אין פרמטר שאילתה ?event= - ומחזיר את המאפיינים שנצפו בו בפועל: הטיפוס שכל אחד נפתר אליו ומהיכן הגיע (typeSource הוא declared, canonical או inferred), בכמה אירועים הוא מופיע (occurrences), ערכי דוגמה, והאם הערכים נראים כמזהה. אין שדה fillRate - חלקו את occurrences ב-totalCount של האירוע ממסלול הרשימה. מאפיין שהוצהר ומעולם לא נשלח הוא הסיבה הרגילה לסגמנט שלא תואם לאף אחד.

תגובת הרשימה:

{
  "data": [
    { "name": "Order Completed", "totalCount": 48210, "uniqueUsers": 31877,
      "lastSeen": "2026-08-27T09:12:00.000Z", "propertyCount": 6,
      "description": "A purchase was completed", "descriptionSource": "platform", "isPlatform": true }
  ],
  "pagination": { "total": 42, "limit": 50, "offset": 0, "hasMore": false }
}

תגובה לאירוע בודד:

{
  "eventName": "Order Completed",
  "properties": [
    { "name": "total", "type": "number", "typeSource": "canonical", "typeDeclared": false,
      "typeMixed": false, "typeCounts": { "string": 0, "number": 48210, "boolean": 0, "array": 0, "object": 0 },
      "typeReason": "single", "occurrences": 48210, "exampleValues": [129.9, 42.5],
      "cardinalityVerdict": "high_cardinality", "uniquenessRatio": 0.31, "looksLikeIdentifier": false,
      "pii": false },
    { "name": "coupon", "type": "string", "typeSource": "inferred",
      "typeMixed": false, "typeCounts": { "string": 3857, "number": 0, "boolean": 0, "array": 0, "object": 0 },
      "typeReason": "single", "occurrences": 3857, "exampleValues": ["SPRING10"],
      "cardinalityVerdict": "low_cardinality", "uniquenessRatio": 0.004, "looksLikeIdentifier": false,
      "pii": false }
  ]
}

exampleValues ריק עבור מאפיין PII כשלמבצע הקריאה אין הרשאה לצפות ב-PII (pii מציין אילו). typeMixed עם typeCounts מסמן מאפיין שערכיו מגיעים ביותר מטיפוס אחד.

הצהרת סכימת אירוע

POST /events/schema

רושמת תיאור לאירוע. אירועים נשארים ללא סכימה: התיאור נשמר במילון הנתונים של מרחב העבודה, שבוררי המאפיינים והעוזר החכם קוראים ממנו - שום דבר אינו מתוקף או נדחה, ולא מוצהרים כאן מאפיינים.

גוף הבקשה:

{ "name": "Order Completed", "description": "A purchase was completed" }

תגובה:

{ "success": true, "message": "Event schema defined successfully",
  "data": { "name": "Order Completed", "description": "A purchase was completed" } }

תיאורי מאפיינים נכתבים דרך PUT /events/schema/:eventName ({ "description"?, "properties"?: [{ "name", "description" }] }). המסלול POST /events/schema/:eventName/properties ({ "name", "type", "description"? }) מצהיר על טיפוס המאפיין - string, number, boolean או date - באותו מילון נתונים; מסלול האירוע הבודד מדווח עליו אז עם typeSource: "declared", ומסנני הסגמנטים משווים לפיו. טיפוס לא מוכר, וכן מאפיין סטנדרטי שהפלטפורמה קובעת את טיפוסו (total, price...), נדחים ב-400.

קטלוג אירועי הפלטפורמה

GET /events/platform-catalog

האירועים הקנוניים ש־Joryio מבינה באופן מובנה, עם המאפיינים שכל אחד מהם מצפה להם. התאימו את השמות האלה והדוחות, הטריגרים ותכונות המסחר האלקטרוני המובנים יעבדו בלי מיפוי; השתמשו בשמות משלכם והם לא.

אירועים נפוצים

אירועי מסחר אלקטרוני

// Product Viewed
POST /users/track
{
  "userId": "user_123",
  "eventName": "Product Viewed",
  "properties": {
    "productId": "prod_456",
    "productName": "Premium Plan",
    "category": "Subscription",
    "price": 99.99,
    "currency": "USD"
  }
}

// Added To Cart
POST /users/track
{
  "userId": "user_123",
  "eventName": "Added To Cart",
  "properties": {
    "productId": "prod_456",
    "quantity": 1,
    "price": 99.99
  }
}

// Order Completed
POST /users/track
{
  "userId": "user_123",
  "eventName": "Order Completed",
  "properties": {
    "orderId": "order_789",
    "total": 249.99,
    "currency": "USD",
    "itemCount": 3,
    "discount": 25.00,
    "paymentMethod": "credit_card"
  }
}

אירועי מחזור חיי משתמש

// Signup Completed
POST /users/track
{
  "userId": "user_123",
  "eventName": "Signup Completed",
  "properties": {
    "method": "email",
    "source": "homepage_cta"
  }
}

// Onboarding Completed
POST /users/track
{
  "userId": "user_123",
  "eventName": "Onboarding Completed",
  "properties": {
    "stepsCompleted": 5,
    "timeSpent": "8m 30s"
  }
}

// Trial Started
POST /users/track
{
  "userId": "user_123",
  "eventName": "Trial Started",
  "properties": {
    "plan": "premium",
    "trialDays": 14
  }
}

אירועי מעורבות

// Feature Used
POST /users/track
{
  "userId": "user_123",
  "eventName": "Feature Used",
  "properties": {
    "featureName": "export",
    "exportFormat": "csv",
    "recordCount": 1500
  }
}

// Page Viewed
POST /users/track
{
  "userId": "user_123",
  "eventName": "Page Viewed",
  "properties": {
    "page": "/pricing",
    "category": "Marketing",
    "referrer": "google"
  }
}

מאפייני אירוע

שיטות עבודה מומלצות

השתמשו בשמות מאפיינים תיאוריים:

טוב:

{
  "properties": {
    "productId": "prod_123",
    "productName": "Premium Plan",
    "price": 99.99,
    "currency": "USD"
  }
}

לא טוב:

{
  "properties": {
    "pid": "prod_123",
    "n": "Premium Plan",
    "p": 99.99
  }
}

סוגי נתונים נתמכים

{
  "properties": {
    "string": "value",
    "number": 99.99,
    "integer": 5,
    "boolean": true,
    "date": "2024-01-15T10:30:00Z",
    "array": ["tag1", "tag2"],
    "object": {
      "nested": "value",
      "deep": {
        "property": "value"
      }
    }
  }
}

מאפיינים שמורים

מאפיינים שמתחילים ב־$ שמורים לשימוש המערכת:

$app_id - מזהה אפליקציה
$app_name - שם אפליקציה
$platform - פלטפורמה (web, ios, android)
$session_id - מזהה סשן
$anonymous_id - מזהה משתמש אנונימי

אל תשתמשו בשמות אלה למאפיינים מותאמים אישית.

שמות אירועים שמורים

שמות אירועים שמתחילים ב-canvas. שמורים לאירועי מסע של Joryio - את canvas.step.entered, canvas.step.left, canvas.experiment.entered וכל שם אחר שמתחיל ב-canvas. רושם רק מנוע המסע (אירועי פלטפורמה). אירוע שאתם שולחים בשם שמתחיל ב-canvas. נדחה (שנו את השם) - האירוע מופיע כנכשל, עם הסיבה, בתשובה של POST /users/track, דחייה קבועה (rejectedIndices) באצוות SDK, ושורה שדולגה עם הסיבה בייבוא CSV או בסנכרון מחסן נתונים. גם המאפיין $emitted_by מוסר מכל אירוע שאתם שולחים.

שמות שמתחילים ב-message. או ב-in_app. שמורים באותו אופן לאירועי ההודעות של Joryio - שליחות, מסירות, פתיחות והקלקות (message.sent, message.opened, message.clicked וכו') וכן הצגות, הקלקות וסגירות של הודעות in-app (in_app.displayed, in_app.clicked וכו') נרשמים רק על ידי Joryio, כך שאירוע מותאם אישית לעולם לא נספר כאחד מהם בדוחות, במסנני סגמנטים או בטריגרים של מסעות. אירוע שאתם שולחים בשם כזה נדחה באותו אופן, כולל שורות בייבוא CSV היסטורי או בסנכרון מחסן נתונים - שנו את השם (למשל Newsletter Opened). הבדיקה מתעלמת מאותיות גדולות וקטנות. אישורי מסירה והקלקות של Push שה-SDK מדווחים, ואירועי in-app שמדווחים דרך נקודות הקצה של in-app ב-SDK, הם אירועים של Joryio עצמה וממשיכים לעבוד.

מגבלות אירועים

מגבלות גודל

מגבלה	ערך
האורך המרבי של שם אירוע	255 תווים
האורך המרבי של מזהה (userId, anonymousId, sessionId, deviceId, clientEventId)	255 תווים
המספר המרבי של מפתחות ברמה העליונה לאירוע	200
הגודל המרבי של מאפיינים (JSON)	50 KB
עומק הקינון המרבי של מאפיינים	5 רמות
מספר האירועים המרבי בבקשה עם גוף מערך	500

מגבלות קצב

ל־Events API אין כיום מגבלות קצב קבועות לכל נקודת קצה - ראו סקירת API: מגבלות קצב.

תגובות שגיאה

כל השגיאות משתמשות בגוף השגיאה הסטנדרטי - ראו סקירת API: תגובת שגיאה.

400 Bad Request - כשל תיקוף

{
  "statusCode": 400,
  "message": "Bad Request Exception",
  "timestamp": "2026-01-15T10:30:00.000Z",
  "path": "/api/users/track",
  "errors": [
    "eventName should not be empty"
  ]
}

400 Bad Request - מאפיינים גדולים מדי

{
  "statusCode": 400,
  "message": "Event properties exceed maximum size of 50KB (received 63KB)",
  "timestamp": "2026-01-15T10:30:00.000Z",
  "path": "/api/users/track"
}

שיטות עבודה מומלצות

1. שלחו אירועים באצווה כשאפשר

טוב - אצווה של כמה אירועים עם גוף מערך:

await fetch('/api/users/track', {
  method: 'POST',
  body: JSON.stringify([event1, event2, event3])
});

לא טוב - בקשות נפרדות:

await fetch('/api/users/track', { method: 'POST', body: JSON.stringify(event1) });
await fetch('/api/users/track', { method: 'POST', body: JSON.stringify(event2) });
await fetch('/api/users/track', { method: 'POST', body: JSON.stringify(event3) });

2. השתמשו בשמות אירועים עקביים

עקבו אחרי התבנית "Object + Past Tense Verb":

טוב: Product Viewed, Order Completed, Trial Started לא טוב: view_product, clicked, user_action_123

3. כללו חותמות זמן

לאירועים היסטוריים, תמיד כללו חותמות זמן מדויקות:

{
  "userId": "user_123",
  "eventName": "Order Completed",
  "timestamp": "2024-01-15T10:30:00.000Z", // Actual event time
  "properties": { ... }
}

4. שמרו על מאפיינים רזים

כללו רק מאפיינים רלוונטיים:

טוב:

{
  "eventName": "Order Completed",
  "properties": {
    "orderId": "order_123",
    "total": 99.99,
    "currency": "USD"
  }
}

לא טוב:

{
  "eventName": "Order Completed",
  "properties": {
    "orderId": "order_123",
    "total": 99.99,
    "currency": "USD",
    "userAgent": "Mozilla/5.0...", // Too much detail
    "sessionData": { /* large object */ },
    "cookies": [ /* array of cookies */ ]
  }
}

5. טפלו בשגיאות בצורה אלגנטית

מימשו לוגיקת ניסיונות חוזרים עם backoff מעריכי:

async function trackWithRetry(event, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      const response = await fetch('/api/users/track', {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${API_KEY}`,
          'Content-Type': 'application/json'
        },
        body: JSON.stringify(event)
      });

      if (response.ok) return await response.json();

      if (response.status === 429) {
        const retryAfter = response.headers.get('Retry-After') || Math.pow(2, i);
        await sleep(retryAfter * 1000);
        continue;
      }

      throw new Error(`HTTP ${response.status}`);
    } catch (error) {
      if (i === maxRetries - 1) throw error;
      await sleep(Math.pow(2, i) * 1000); // 1s, 2s, 4s
    }
  }
}

דיבוג

הפעלת מצב Debug (SDK)

כאשר משתמשים ב־Web SDK:

import JoryioSDK from '@joryio/web-sdk';

const joryio = new JoryioSDK({
  sdkKey: 'jry_sdk_web_...',
  enableDebug: true // Log all events to console
});

אימות אירועים בלוח הבקרה

עברו אל Users → חפשו משתמש
לחצו על לשונית Activity
ראו את כל האירועים שנאספו

תקלות נפוצות

אירועים לא מופיעים:

ודאו שמפתח ה־API נכון
ודאו שהמשתמש מזוהה
ודאו ששם האירוע והמאפיינים תקינים
בדקו מגבלות קצב

מאפיינים לא מופיעים:

ודאו ששמות המאפיינים נכונים
בדקו שסוגי הנתונים נתמכים
הימנעו משמות מאפיינים שמורים (תחילית $)

SDKs

להטמעה קלה יותר, השתמשו ב־SDKs הרשמיים:

Web SDK: מדריך שילוב
iOS SDK: Swift Package / CocoaPods
Android SDK: Gradle
React Native SDK: npm install @joryio/react-native-sdk

אימות​

אירוע הרכישה​

למה רק שם אחד​

על הסכומים​

אם אתם כבר שולחים שם אחר​

קודי קופון באירוע​

חנות וערוץ מכירה באירוע​

שליחת אירועים​

Query Events​

Endpoint​

פרמטרי שאילתה​

דוגמת בקשה​

תגובה​

Event Aggregation​

Endpoint​

גוף בקשה​

דוגמת בקשה​

תגובה​

מדדים נתמכים​

דוגמה: ניתוח הכנסות​

דוגמה: שימוש ביכולת לפי שעה​

גילוי מה מרחב העבודה שולח​

שמות אירועים​

סטטיסטיקת אירועים​

סכימות אירועים​

הצהרת סכימת אירוע​

קטלוג אירועי הפלטפורמה​

אירועים נפוצים​

אירועי מסחר אלקטרוני​

אירועי מחזור חיי משתמש​

אירועי מעורבות​

מאפייני אירוע​

שיטות עבודה מומלצות​

סוגי נתונים נתמכים​

מאפיינים שמורים​

שמות אירועים שמורים​

מגבלות אירועים​

מגבלות גודל​

מגבלות קצב​

תגובות שגיאה​

400 Bad Request - כשל תיקוף​

400 Bad Request - מאפיינים גדולים מדי​

שיטות עבודה מומלצות​

1. שלחו אירועים באצווה כשאפשר​

2. השתמשו בשמות אירועים עקביים​

3. כללו חותמות זמן​

4. שמרו על מאפיינים רזים​

5. טפלו בשגיאות בצורה אלגנטית​

דיבוג​

הפעלת מצב Debug (SDK)​

אימות אירועים בלוח הבקרה​

תקלות נפוצות​

SDKs​

צעדים הבאים​

אימות

אירוע הרכישה

למה רק שם אחד

על הסכומים

אם אתם כבר שולחים שם אחר

קודי קופון באירוע

חנות וערוץ מכירה באירוע

שליחת אירועים

Query Events

Endpoint

פרמטרי שאילתה

דוגמת בקשה

תגובה

Event Aggregation

Endpoint

גוף בקשה

דוגמת בקשה

תגובה

מדדים נתמכים

דוגמה: ניתוח הכנסות

דוגמה: שימוש ביכולת לפי שעה

גילוי מה מרחב העבודה שולח

שמות אירועים

סטטיסטיקת אירועים

סכימות אירועים

הצהרת סכימת אירוע

קטלוג אירועי הפלטפורמה

אירועים נפוצים

אירועי מסחר אלקטרוני

אירועי מחזור חיי משתמש

אירועי מעורבות

מאפייני אירוע

שיטות עבודה מומלצות

סוגי נתונים נתמכים

מאפיינים שמורים

שמות אירועים שמורים

מגבלות אירועים

מגבלות גודל

מגבלות קצב

תגובות שגיאה

400 Bad Request - כשל תיקוף

400 Bad Request - מאפיינים גדולים מדי

שיטות עבודה מומלצות

1. שלחו אירועים באצווה כשאפשר

2. השתמשו בשמות אירועים עקביים

3. כללו חותמות זמן

4. שמרו על מאפיינים רזים

5. טפלו בשגיאות בצורה אלגנטית

דיבוג

הפעלת מצב Debug (SDK)

אימות אירועים בלוח הבקרה

תקלות נפוצות

SDKs

צעדים הבאים