הגדרת ניסויים ובדיקות A/B באמצעות דגלי תכונות

הקצאות של feature flag ב-App Lifecycle Manager עוזרות לכם לבדוק את האפליקציה על ידי חלוקה של אחוזי התנועה. כך חלק מהמשתמשים יראו וריאנט אחד של האפליקציה, ומשתמשים אחרים יראו וריאנט אחר. זה יעזור לכם לקבוע אילו וריאנטים או תכונות מוצלחים יותר (התהליך הזה נקרא לעיתים קרובות בדיקת A/B). הקצאות של feature flag עוזרות לכם להגדיר איך לפצל את התנועה ולשלב את הווריאציות שהוקצו באפליקציה.

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

כדי לפשט את המעקב והניתוח, כדאי להקצות מזהים של מחרוזות תיאוריות לגרסאות (לדוגמה, experimental ו-baseline) ולהשתמש בשמות האלה ישירות בקוד ובצינורות הניתוח.

דרישות מוקדמות

לפני שמתחילים, חשוב לוודא שיש לכם:

  1. השלמתם את המדריך למתחילים בנושא פריסת דגלי תכונות או את המדריך למתחילים בנושא שימוש בדגלי תכונות (מדריך עצמאי למתחילים).
  2. סביבת Google Cloud CLI שמוגדרת לניהול משאבים של App Lifecycle Manager.

הגדרת הקצאה של דגל תכונה

כדי להגדיר feature flag ניסיוני:

  1. מגדירים את המאפיין האקראי (למשל, userID) שישמש להקצאה קבועה של משתמשים לקבוצות כדי להבטיח חוויה עקבית לכל משתמש.

      gcloud beta app-lifecycle-manager flags attributes create "user-id-attr" \
      --key="userID" \
      --attribute-value-type="STRING" \
      --location=global

  2. משתמשים בהקצאה כדי להגדיר את החלוקה (לדוגמה, 50/50), תוך הפניה למזהי הווריאציות התיאוריים.

    # Create a flag with explicitly named variants for the experiment and a 50/50 allocation referencing the custom IDs
gcloud beta app-lifecycle-manager flags create "search-algo-test" \
  --key="search-algo-test" \
  --flag-value-type=BOOL \
  --location="global" \
  --unit-kind="demo-test-unitkind" \
  --variants='[
      {
      "id": "experimental",
      "booleanValue": true
      },
      {
      "id": "baseline",
      "booleanValue": false
      }
  ]'\
  --evaluation-spec='{
      "allocations": [{
          "id": "search-split-50-50",
          "randomizedOn": "userID",
          "slots": [
          {"variant": "baseline", "weight": 50},
          {"variant": "experimental", "weight": 50}
          ]
      }],
      "defaultTarget": "search-split-50-50",
      "attributes": ["projects/PROJECT_ID/locations/global/flagAttributes/user-id-attr"]
  }'

  3. בשירות הקצה העורפי, מאתחלים את OpenFeature SDK ומזריקים את userID להקשר ההערכה. משתמשים בשיטה BooleanValueDetails (או בשיטה מקבילה בשפה שלכם) כדי לאחזר את variantID (מחרוזת) באפליקציה. כך תוכלו לשנות את הלוגיקה של ה-Backend על סמך השם התיאורי ולא רק על סמך ערך בוליאני.

    // 1. Prepare evaluation context
evalCtx := map[string]any{"userID": currentUser.ID}

// 2. Fetch evaluation details to get the variant name
details, err := client.BooleanValueDetails(ctx, "search-algo-test", false, evalCtx)

// 3. Execute logic based on the Variant ID (string name)
if details.Variant == "experimental" {
    results = search.ExperimentalV2(query)
} else {
    results = search.BaselineV1(query)
}

  4. כדאי להשתמש בשמות וריאנטים תיאוריים כדי שהתיעוד ייווצר אוטומטית במהלך הביקורת והניתוח. כדי לבצע ביקורת על ההערכות, צריך לרשום ביומן את המחרוזת details.Variant לצד מדדי הביצועים:

     startTime := time.Now()
 // ... perform search ...
 duration := time.Since(startTime)

 // Audit: Log the descriptive variant name ("experimental" or "baseline")
 logger.Info("Search performed",
    "variant", details.Variant,
    "latency_ms", duration.Milliseconds(),
 )

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

המאמרים הבאים