enhancement and fix for LinkedIn CAPI tag

[otyeung]

Changes made :

1. Add lead as an optional parameter, assuming lead id is passed in EventModel.leadID
2. Add apiversion as a parameter configuration, currently it's hardcoded to 202307 in the tag template
3. Hash Email Enhancement : if EventModel.user_data.email is set and EventModel.user_data.sha256_email_address is not set, the code will do SHA256 hashing and pass hashed value to CAPI.
4. Fix an issue where Conversion Value is not optional, currently if conversionCurrency & conversion Value is not set in EventModel and Conversion Value is blank in the tag, the code will will send {"currencyCode": "", "amount": ""}, getting 400 Error Code

[mithredate]

Great work @otyeung 🎉 Just one small note:

According to Google's server-side common event data doc, it should be EventModel.user_data.email_address and not email. 🙂

[otyeung]

Hi @mithredate

Great catch! I've fixed this in this branch, please kindly review & take a look!

Apart from that, I've added several enhancements:

1. For those CAPI optional parameters, if they are not set, it won't be added to the payload.
2. Normalized email address (lowercase) and then hash it, if hashed email address is not set but email is set in user_data.
3. LinkedinFirstPartyId will be checked if it is set in user_data via gtag function, if it's not set that way, the code will check if it is set at "x-ga-mp2-user_properties", it allows user to read cookie directly thru GTM and pass that value in "User Parameters"

Ping me via Slack or Teams if you want to discsuss.

[desaip]

Thank you so much @otyeung for raising this PR! Sorry we missed seeing this PR earlier. We'll be gradually updating the template with enhancements and incorporate most of your updates. We'll keep you posted. cc @SurendraJambeLI

[ZLeventer]

Solid set of improvements. A few observations from working in this codebase recently (PRs #15–#19):

1. The conversionValue handling needs a guard against undefined — if the GTM variable isn't set, the API call fails silently. I addressed this specifically in #15.

2. For the email hashing logic: the CAPI spec accepts both SHA256_EMAIL (pre-hashed) and plaintext email (which the tag should hash client-side before sending). If this PR touches email handling, worth confirming it normalizes (lowercase + trim) before hashing per LinkedIn's docs.

3. The li_fat_id cookie read is a good addition if included here — that's the LinkedIn first-party ads tracking ID and is the highest-signal match key after email.

Overall this looks like a meaningful improvement over the baseline template. Would be good to get it or a subset merged — the template has had several overlapping PRs open for 1-2 years addressing similar gaps.