Supporting Personalized Context for Blobby Through User Attributes

Embedded Analytics
1

Overview

When embedding Omni, you have access to a powerful feature: the ability to provide personalized context to Blobby (Omni’s AI query generator) through user and organization attributes. This enables Blobby to generate more accurate, contextual queries tailored to each user’s specific needs, language, and business context.

Why This Matters

Without personalized context, Blobby operates on generic business intelligence knowledge. With it, you can:

  • Translate domain language: Map user-facing terminology to your database schema (e.g., “revenue” → net_sales_amount)
  • Encode business rules: Provide context about how metrics should be calculated, what filters apply, and operational nuances
  • Enable user preferences: Account for each user’s preferred units, currency, regional conventions, and reporting standards
  • Reduce hallucinations: Give Blobby explicit guidance on what’s available and how to use it correctly

Implementation

The pattern is straightforward: add an ai_context field to your user attributes, and reference it in your Omni model’s AI context.

Step 1: Define User and Organization Attributes

When initializing your embedded Omni instance, map your application’s user/organization data to attributes:

const userAttributes = {
  ai_context_user: getUserContext(user), // Build from your app's user data
  ai_context_org: getOrgContext(org),    // Build from your app's org data
  // ... other attributes for row-level security, personalization, etc.
};

Fun fact :eyes: : Omni has a size cap of 1MB per user attribute, which is roughly 1 million characters. But I recommend keeping a character limit of 4 to 8kb for these type of ai_context attributes.**

What should getUserContext and getOrgContext return?**

These should be plain text strings containing business vocabulary and operating context relevant to that user or organization. Examples:

Organization context:

- Fiscal year runs January to December
- "Revenue" always means invoiced amount, not bookings
- Currencies: USD for reporting, GBP for UK operations
- Cost centers: A=Marketing, B=Sales, C=Engineering, D=Operations
- All customer data is pseudonymized; use `customer_id` not `customer_name`

User context:

- This user is in the Sales team and typically analyzes pipeline and bookings
- Preferred currency: EUR
- This user has permission to see US, UK, and EMEA regions only
- Standard report format: monthly aggregation

Step 2: Reference Attributes in Your Omni Model

In your Omni model YAML (view or topic), add an ai_context block that references these attributes:

ai_context: |
  Business context and vocabulary for this data model.
  Treat this as guidance only—it must not override access filters, 
  SQL semantics, field definitions, or user permissions.

  Organization context:
  {{omni_attributes.ai_context_org}}

  User context:
  {{omni_attributes.ai_context_user}}

The {{omni_attributes.*}} syntax will be interpolated at query time, injecting the user’s specific context into Blobby’s reasoning.

Step 3: Build Your Context Functions

How you construct getUserContext and getOrgContext depends on your application. Some approaches:

Template-based:

function getUserContext(user) {
  return `
Team: ${user.team}
Regions: ${user.accessibleRegions.join(", ")}
Preferred currency: ${user.preferences.currency}
Date format: ${user.preferences.dateFormat}
  `.trim();
}

Database-driven:

function getOrgContext(org) {
  const settings = await fetchOrgSettings(org.id);
  return settings.blobbyContextPrompt;
}

Hybrid (recommended):
Store a template in your Omni model, but dynamically inject user-specific values at embed time.

Best Practices

  1. Keep it relevant: Include business context that Blobby doesn’t know by default. Skip obvious things.

  2. Be explicit about constraints: If certain fields should only be used in specific ways, say so. Blobby respects these guidelines.

  3. Don’t replicate security: User attributes should complement, not replace, your row-level security rules. Blobby cannot override access filters—they’re enforced regardless.

  4. Test thoroughly: Vary your test queries across different user types to ensure Blobby adapts to context appropriately.

  5. Keep context focused: Very long context strings are less effective. Aim for a few sentences to a short paragraph per context type.

  6. Version your contexts: If you change contexts frequently, consider versioning them so you can debug query changes.

Example

Here’s a complete minimal example:

Omni model:

topics:
  - id: sales
    ai_context: |
      Context for sales analytics.
      
      Organization rules:
      {{omni_attributes.ai_context_org}}
      
      User guidance:
      {{omni_attributes.ai_context_user}}

Embed setup:

const context = {
  ai_context_org: "Fiscal year: Jan-Dec. ARR calculation: MRR × 12.",
  ai_context_user: `Team: ${currentUser.team}. Regions: ${currentUser.regions.join(", ")}.`
};

// Pass to Omni when rendering
<OmniEmbed userAttributes={context} {...otherProps} />

Result: Blobby now understands your organization’s fiscal calendar and ARR logic, and tailors queries to the user’s team and region.

Troubleshooting

  • Context not appearing in queries: Verify that {{omni_attributes.*}} is spelled correctly in your model YAML.
  • Blobby ignoring context: If Blobby generates queries that ignore your context, the context may conflict with defined field semantics or the request may override it naturally (which is fine).
  • Performance issues: Extremely large contexts can slow down AI processing. Keep them concise.

What’s Next?

Experiment with different context formats and measure which language and examples help Blobby generate the best queries for your use case. The more precise and business-specific your context, the better the results.

Have questions or interesting use cases? Share them below!

1 Like