Data 360: Troubleshooting Mobile SDK Data Ingestion Issues

To resolve issues where records are not appearing in Data 360 after Mobile SDK integration, review the following checklist:

1. Schema Case Sensitivity

• Ensure that the schema field names are case-sensitive and follow camelCase conventions.

• Field names in the schema must match the exact casing of the incoming data fields.

• Example: If your data contains a field like contactId, your schema should not define it as ContactID or contactid.

2. Field Naming Consistency

• Double-check that the field names in your uploaded schema exactly match those in your data payload.

• Any mismatch—even in capitalization—can prevent Data 360 from ingesting those records.

• Example: Data field: contactId; Schema must also say contactId.

3. Creating New Fields

• If you identify that a field name in the schema is incorrect or does not follow the expected case sensitivity, please be aware that existing field names cannot be renamed, nor can new fields be created with the same name using different casing.

• To resolve this:

• • Option 1: Create a new connector configuration using a corrected schema that includes properly formatted field names.

  • Option 2: Introduce a new field name that adheres to naming best practices (e.g., contactIdentifier) and update the source system to send data to this new field.

4. Passing Mandatory Fields in the Events:

The Data 360 event beacon requires the following fields to be present on all events. These fields are automatically assigned by the Mobile SDK and should not be manually populated from the source system. Any custom values sent from the source for these fields will be ignored during ingestion. Ensure your source system does not attempt to override these values, as they are managed entirely by the SDK.

5. Understanding Schema Field Naming Rules — Explained Simply

To make sure your event data is accepted and processed correctly by Data 360 when sent through the Mobile SDK, it needs to follow some specific rules about how the fields (or “columns”) are named.

Here’s what you need to know:

• Keep Field Names Simple: Use straightforward names without complicated nesting or layers whenever possible.

• Camel Case Naming:

  • If your field names use uppercase letters, underscores (_), or spaces, the system will automatically change them to “camel case.”

  • This means the first word is lowercase and each new word starts with a capital letter.

  • Example:

    • PROMO_CODE becomes promoCode

    • user_id becomes userId

• No Special Characters or Spaces:

  • If your field names include spaces or special characters like #, ', or !, these will be removed to keep the name clean.

  • Example:

    • special #size's becomes specialSizes

    • address line 1 becomes addressLine1

    • order-total! becomes orderTotal

• Naming for Nested Fields:

  • When your data includes groups inside groups (nested attributes), the system joins these names together to make one combined field name.

  • Example:

    • If you have: "carDetails": {"color": "red"}, the field name in the schema becomes: carDetailsColor

• Handling Arrays (Lists):

  • When you have a list of simple items (like a list of strings), the system creates separate fields for each item by adding numbers at the end.

  • Example:

    • "fruits": ["apple", "banana"]. The schema fields will be:

      • fruits0: "apple"

      • fruits1: "banana"