Developer Guide
Visit our Knowledge BaseDeveloper CommunityRequest a Demo

Login

Reports that the user completed the signup process and is a registered user. Identification event.

Suggest Edits

👍

Use this event similarly to the Signup event

Both identify a user. Use Login to identify an already-registered user, and use Signup to report a new user registration. Read the guide section about Events Identifying a Customer Across Channels for more information.

The registered customer unique ID (CUID) you pass in this event can be either a hashed email address or a custom type. You can:

  • Report the event with a hashed email address, enabling you to use email features (and onboard first-party data, for which the primary key is typically the hashed email address).
  • Report the event with a non-email CUID type. Specify the type by setting the cuidType property. For example, pass crmId to designate identifiers created internally in your CRM. If cuidType is not set, a default named id type is used.
  • If you report the event without any identifier, it simply tracks that a login occurred but not by whom. It registers a warning in your implementation health report, but the event still serves for tracking and targeting purposes.

Parameters

  • name: Human-readable name, not used to identify an event type
  • properties: A container for the event properties as specified in the following table:
PropertyDescriptionType
dyTypeMust be "login-v1"String
cuid
Optional		User identifier value.
! Must not include a / character | Max string length is 250		String
cuidType

Optional		Use this identifier type to identify users across devices (for example, customer_id, account_id, or hefor SHA-256 hashed email).
Note: Do not include any personal information in this ID.		String
secondaryIdentifiers
type, value		Optionally, add a second method for identification across devices and Experience OS apps. Your secondary identifier can be anything you decide, including a hashed email address, phone number, CRM ID, e-commerce ID, and so on. You must define the identifier type in your section settings .

If you decide to use a phone number as the secondary identifier, handle it as follows:
Script-based event: Type: phoneNumber, Value: Phone number
Must be E.164 format (+ and country code and phone number, no spaces or symbols. For example, +12195551212, +49555343333.)
API-based event: Type: hashedPhoneNumber, Value: SHA-256 hashed phone number		String
Note:
Identifiers with special requirements		 Hashed email (he) and hashed phone number (hashedPhoneNumber) must use SHA-256 hashing.
Phone number (phoneNumber) must conform to the E.164 format. Contact your technical account manager to enable using phoneNumber as an identifier in your script-based events.

📌

Using the secondary identifier

As soon as you report a secondary identifier for a user, that ID is mapped to the user no matter which device is used or which event is reported. Until it's overriden with a new value, it exists for the user whether or not it's re-reported in an API or script-based event.

👍

Tip:

You can use the following out-of-the-box script function to hash email addresses:
DYO.dyhash.sha256("[email protected]".toLowerCase())

Make sure you then set cuidType as he.

Example: Implementation via script

DY.API("event", {
  name: "Login",
  properties: {
    dyType: "login-v1",
    cuid: "156498191",
    cuidType: "EcommerceID"
  }
});

Example: Implementation via script, using secondary identifiers

DY.API("event", {
  name: "Login",
  properties: {
    dyType: "login-v1",
    cuid: "62eccc43b550b012b7ea7fb07e64baafb1508d8b715a55148ccf0f3322eab1a1",
    cuidType: "he",
    secondaryIdentifiers: [
      { type: "phoneNumber", value: "+12195551212" },
      { type: "ecommerceID", value: "12345" },
      { type: "vipClub", value: "678910" }
    ]
  }
});

Example: Implementation via Experience API (server-side)

"events": [
        {
          "name": "Login",
          "properties": {
            "dyType": "login-v1",
            "cuidType": "clientId", 
            "cuid": "62eccc43b550b012b7ea7fb07e64baafb1508d8b715a55148ccf0f3322eab1a1"
          }
        }
      ]

Example: Implementation via Experience API (server-side), using secondary identifiers

"events": [
        {
          "name": "Login",
          "properties": {
            "dyType": "login-v1",
             "cuid": "62eccc43b550b012b7ea7fb07e64baafb1508d8b715a55148ccf0f3322eab1a1",
        "cuidType": "clientId",
        "secondaryIdentifiers": [
          { "type": "hashedPhoneNumber", "value": "49c7b1f6d24121078d8f37997b433586fe9a28e2dc4fbd0803eac237ac82255e" },
          { "type": "ecommerceID", "value": "12345" },
          { "type": "vipClub", "value": "678910" }
        ]
      }
    }
  ]

👍

Go to the API reference for the Events endpoint to learn more.

Updated about 1 month ago