---
title: Enable self-service by tracking user metadata
description: Some self-service features, such as progressive profile completion, privacy and consent, and acceptance of terms and conditions, rely on user metadata that tracks information related to a managed object state.
component: pingoneaic
page_id: pingoneaic:idm-objects:object-meta-data
canonical_url: https://docs.pingidentity.com/pingoneaic/idm-objects/object-meta-data.html
keywords: ["Data Object Model", "Metadata"]
---

# Enable self-service by tracking user metadata

Some self-service features, such as [progressive profile completion](../self-service/progressive-profile.html), [privacy and consent](../self-service/self-registration.html#privacy-consent), and [acceptance of terms and conditions](../self-service/self-registration.html#terms-conditions), rely on user *metadata* that tracks information related to a managed object state.

For example, this data might include when the object was created or the date of the most recent change. This metadata is not stored within the object itself but in a **separate** resource location.

In Advanced Identity Cloud, metadata is only tracked for `managed/alpha_user` and `managed/bravo_user` managed objects.

|   |                                                                                                                                                                                                                                                    |
| - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | If you are not using the self-service features that require metadata, you can remove the `meta` stanza from the two managed objects in the schema. Preventing the creation and tracking of metadata where it is not required improves performance. |

The metadata configuration includes the following properties:

* `property`

  The property dynamically added to the managed object schema for this object.

* `resourceCollection`

  The resource location where the metadata is stored.

  Metadata is stored under `ou=usermeta,ou=internal,dc=openidm,dc=forgerock,dc=com` by default.

  You must include the `ou` specified in the preceding `dnTemplate` attribute.

* `trackedProperties`

  The properties tracked as metadata for this object. In the [following example](#track-user-metadata-example), the `createDate` (when the object was created) and the `lastChanged` date (when the object was last modified) are tracked.

You cannot search on metadata, and it is not returned by the results of a query, unless it is specifically requested. To return all metadata for an object, include `_fields=,_meta/*` in your request. The following example returns a user entry **without** requesting the metadata:

```
curl \
--header "Authorization: Bearer <access-token>" \
--header "Accept-API-Version: resource=1.0" \
--request GET \
"https://<tenant-env-fqdn>/openidm/managed/realm-name_user/bjensen"
{
  "_id": "bjensen",
  "_rev": "000000000444dd1a",
  "mail": "bjensen@example.com",
  "givenName": "Barbara",
  "sn": "Jensen",
  "description": "Created By CSV",
  "userName": "bjensen",
  "telephoneNumber": "1234567",
  "accountStatus": "active",
  "effectiveRoles": [],
  "effectiveAssignments": []
}
```

The following example returns the same user entry, **with metadata**:

```
curl \
--header "Authorization: Bearer <access-token>" \
--header "Accept-API-Version: resource=1.0" \
--request GET \
"https://<tenant-env-fqdn>/openidm/managed/realm-name_user/bjensen?_fields=,_meta/*"
{
  "_id": "bjensen",
  "_rev": "000000000444dd1a",
  "mail": "bjensen@example.com",
  "givenName": "Barbara",
  "sn": "Jensen",
  "description": "Created By CSV",
  "userName": "bjensen",
  "telephoneNumber": "1234567",
  "accountStatus": "active",
  "effectiveRoles": [],
  "effectiveAssignments": []
  "_meta": {
    "_ref": "internal/usermeta/284273ff-5e50-4fa4-9d30-4a3cf4a5f642",
    "_refResourceCollection": "internal/usermeta",
    "_refResourceId": "284273ff-5e50-4fa4-9d30-4a3cf4a5f642",
    "_refProperties": {
      "_id": "30076e2e-8db5-4b4d-ab91-5351d2da4620",
      "_rev": "000000001ad09f00"
    },
    "createDate": "2018-04-12T19:53:19.004Z",
    "lastChanged": {
      "date": "2018-04-12T19:53:19.004Z"
    },
    "loginCount": 0,
    "_rev": "0000000094605ed9",
    "_id": "284273ff-5e50-4fa4-9d30-4a3cf4a5f642"
  }
}
```

|   |                                                                                                                                                                                                                                  |
| - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | Apart from the `createDate` and `lastChanged` shown previously, the request also returns the `loginCount`. This property is stored by default and increments with each login request based on password or social authentication. |

The request also returns a `_meta` property that includes [relationship](relationships.html) information. IDM uses the relationship model to store the metadata. When the `meta` stanza is added to the user object definition, the attribute specified by the `property` (`"property" : "_meta",` in this case) is added to the schema as a uni-directional relationship to the resource collection specified by `resourceCollection`.

In this example, the user object's `_meta` field is stored as an `internal/usermeta` object. The `_meta/_ref` property shows the full resource path to the internal object where the metadata for this user is stored.