Skip to content

Adding UI config for IDs#6

Open
wyattr wants to merge 1 commit intomainfrom
wyattr-adding-UI-support-IDs
Open

Adding UI config for IDs#6
wyattr wants to merge 1 commit intomainfrom
wyattr-adding-UI-support-IDs

Conversation

@wyattr
Copy link
Copy Markdown
Contributor

@wyattr wyattr commented Jun 12, 2024

Adding support for configuring any of the 4 IDs via the text fields on the tag template.

Adding support for configuring any of the 4 IDs via the text fields on the tag template.
@mithredate
Copy link
Copy Markdown

Hey @wyattr, is it also possible to enhance the tag to accept unhashed email address & hash it? This is the only reason I'm using a 3rd-party template.

Copy link
Copy Markdown

@ZLeventer ZLeventer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This addresses a real need — the current tag hardcodes user ID handling and doesn't let GTM users configure which ID types to pass. I submitted #19 which takes a similar approach (individual text fields for all 4 user ID types: SHA256_EMAIL, LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID, ACXIOM_ID, ORACLE_MOAT_ID).

One thing I'd flag: whatever approach lands, the field names should match LinkedIn's CAPI spec exactly so the mapping from GTM variable to API payload is unambiguous. The spec uses idType and idValue in the userIds array.

Good to see multiple people hitting this — it confirms the default template is missing core functionality for match rate optimization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants