Skip to main content

Custom Object

A Custom Object is a schema-less object that can be attached to a specific account as shown in the below example. It can have a dynamic storage container that is updated with additional fields or data formats on the fly.

A Custom Object should be used if you are looking to store large amounts of user data and the data can’t be formatted in a structured format because the data format could be different for each user. The Custom Object is serviced by the Custom Object Rest APIs. This allows you to store or update complex data objects that would not be easily accessible in a single layer field (Custom Field) such as nested data or object arrays.

Main features of Custom Object:

  • Schema-less data storage object
  • Can store any kind of data/information
  • Can store large amount of data
  • Fully serviced by REST APIs
  • Support data query using REST APIs
  • Auto indexed and normalized in data store
  • Fully managed by LoginRadius
  • An example of Custom Object:
 [
  {
    "Id": "5xxxxxxxxxxxxxxxxxf",
    "IsActive": true,
    "DateCreated": "2015-03-03T21:10:04.83Z",
    "DateModified": "2015-03-03T21:10:04.83Z",
    "IsDeleted": false,
    "Uid": "5xxxxxxxxxxxxxxxxxa",
    "CustomObject": {
      "Test":[
        {
          "field1": "Data3",
          "field2": "Data4",
          "field3": "Data5"
        },
        {
          "field11": "Data31",
          "field21": "Data41",
          "field31": "Data51"
        }
      ]
    }
  }
]

Custom Object Usage

Custom Objects are used to store large amount of data for a user. You can use the various Custom Object Rest APIs to create and delete Custom Objects as well update the stored data.

Custom Object usage Limit for each user

We allow one Custom Object for each user. As it is schema-less, you can store any type of data in any format, so you only need to utilize one Custom Object per user. But if you have a certain scenario that you think requires more than one per user, please send the details to our support team.

Enable Custom Object

Custom Objects are only available in the LoginRadius Enterprise Plan with additional cost. You will need to contact the LoginRadius support team to enable Custom Objects for your account.

Business Use Case of Custom Object

  • Store user’s search history: Track what users search for on your website, such as products, travel bookings, or specific keywords.
  • Shopping list: Store the contents of a user's shopping cart as a Custom Object to retrieve during checkout or when the user returns to the site.
  • Store user’s activity history: Keep a record of user-related activities, including products viewed, articles read, or destinations visited.
  • CRM events/activity list: Record purchase events or service activities to retrieve when the user returns or to sync during CRM integrations.
  • Store purchased product list: Maintain a comprehensive list of all products a user has purchased, including details like product ID, description, and purchase date.
  • Wishlist: Save products a user has added to their wishlist, allowing for easy retrieval during future sessions or checkout.
warning

Impact of Adding New Fields on Indexing

When you introduce new fields into a Custom Object schema, the order in which schema updates and data creation occur is critical for analytics indexing.

If records are created before the Custom Object schema is updated and indexed in your tenant, LoginRadius Analytics will initially infer the field type (typically as text) based on the incoming data.

If the schema is later updated to define the same field with a different data type (for example, explicitly defining it as string, number, or boolean), this mismatch can result in mapping conflicts within the analytics index. In such cases, a reindex may be required to align existing data with the updated schema definition.

Best Practices

To avoid indexing and analytics inconsistencies, LoginRadius strongly recommends the following:

  • Always update the Custom Object schema first: Ensure all new fields (e.g., PersonID, AccountID) are fully defined and indexed before creating or updating records that use those fields.
  • Avoid early data writes to undefined fields: Writing data to fields that are not yet defined in the schema can cause incorrect type inference and indexing issues.
  • Plan for reindexing when schema updates occur late: If records were already created before the schema update, a reindex (or, in some cases, table recreation followed by reindexing) may be required to correct the field mappings.
  • Exercise caution in production environments: Ensure that customers or downstream systems do not create records with new fields until the schema update and indexing configuration are fully completed to avoid disruptive production reindex operations.

Note: Reindexing requirements and supported remediation steps can vary depending on the nature of the schema change and data volume. For guidance on mapping changes, reindexing options, or production impact assessment, please contact Support.