CaaS Link Truncation

[meganthecoder]

Problem:
During bulk updates on bacom, some of the caas links got truncated because they were too long (over 2000 characters). This broke the caas cards on those pages and required manual authoring to fix.

Background:
From what I can tell, we had an issue with truncation during the loc process last year, and @chrischrischris implemented gzip compression for caas links in Oct 2023. PR #1401. Ticket: MWPW-135873

However, even with this compression, we have links over 2000 characters. For example, the caas link on the bacom resource page is 2940 characters. A lot of bacom's new resource topic pages are over the limit because they have a lot of customization.

Ideas on how to solve:

• Is there a better way to compress? Changing the compression format from gzip to deflate-raw will only reduce the length by about 2%, which isn't enough.
• Do we have to include the entire state in the config url or could we include only what options changed from the default?
• Could we shorten the param names?
  The minimum caas url length is 1247 characters (with the default options). If the Microsoft Word max is 2077, that means that we're using more than half of our space with boilerplate. Generally, I'm on the side of making names and labels human-readable, but in this case, it might be worth it to abbreviate the param names to save space.
• Other ideas?
• Also, how do we keep this from happening again in the future? Do we need a cap on the number of caas fields we add?

To note: We're also looking into this on the Microsoft side, but considering how slow that process can be, we're focusing on changes we can make in milo.

[jedjedjedM]

What exactly is limiting us to 2k chars? Have we taken this limitation to MSFT via support case or feature request? Akamai supports URLs in the 8k range and chrome supports up to 2mb.

Brotli compression will help a bit, but still probably not enough (18% savings with my test-case).

For those not deep into milo/caas link lore...
The issue with the milo links is that they represent the state of the configuration tool and are not the final link required by caas. The links in milo are a json object of the configuration tool gzip'd and base64 encoded. These are converted on the fly into a real caas link which is at least half the size. (~1100 chars for the resource center.)

If the caas config tool can build its state using a real caas link instead of a json object, that would probably be the ideal fix. @chrischrischris, do you think that is feasible?

[meganthecoder]

What exactly is limiting us to 2k chars? Have we taken this limitation to MSFT via support case or feature request?

We believe this is a Microsoft limitation. We noticed truncation happening on links around 2000+ characters, and in Chris' ticket he says the Microsoft Word max is 2077. I'm not sure exactly where he got that number, but it's consistent with what we saw.

We want to open a ticket with Microsoft about this, but we need some kind of session id for them to track when the issue happened. (That's what they requested when we opened a ticket about the separate link shuffling issue). We need the id from @garvitjoshi so I'll follow up with him on if we have that.

[meganthecoder]

Update: Sunil is going to bring this up in his meeting with Microsoft

[sanrai]

Adding a few more possible solutions here.

A combination of these fixes will definitely fix/resolve the issue.

I listed these in terms of easiest to hardest to implement (and left other possible solutions out), but relatively, most of these fixes are quite simple.

1. Use different base than 64.
   Using base 85 for example should increase our upper bound by a few extra hundred characters

2. Split the base64 string:
   We could split the base64 encoded JSON into multiple parts, each under 2K characters. Then we reconstruct the full base64 string before decoding and parsing it.

For example:

[part1]base64-data-part-1
[part2]base64-data-part-2
[part3]base64-data-part-3

3. Shorten the URLs and then have some mapping to their encoded values
   We can create a hash of the config object into an id and store some mapping (either as a word table in the simplest case or some external store) and then pull from there.

[meganthecoder]

Thanks for the suggestions! A couple thoughts:

1. I don't see a standard web method for encoding/decoding ascii85. Do you know of one? If not, we'd need a third party library or something, which might have performance impacts.
2. Not sure I understand this idea. Are you proposing that we'd author two or three caas links in a row that all combine to make one card collection?
3. I'd like to avoid something like this if we can because of the performance impact and authoring overhead, but it's something to consider if nothing else pans out.

[sanrai]

Just an FYI since it's not inherently obvious -- compression algorithms like gzip already do this internally as part their algorithm and us doing this would give us no gain.

Could we shorten the param names? Generally, I'm on the side of making names and labels human-readable, but in this case, it might be worth it to abbreviate the param names to save space.

[meganthecoder]

I already tested this and got a small reduction of about 30 characters when abbreviating 4 or 5 params, so I consider it a viable option. It was only a 2.5% reduction though so it won't solve the problem on its own.

[sukamat]

@meganthecoder I believe I mentioned this in one of the earlier meetings related to this topic, but I am reiterating here for clarity.

The character limitation issue can be consistently reproduced in the MS Word Desktop app by inserting a long URL and re-opening the link edit window. Upon doing so, the URL appears truncated. It does not seem that a session ID is required to replicate this behavior.

Based on my previous discussions with Microsoft, they tend to prioritize addressing issues in the MS Word Web app rather than the Desktop version. In most cases, their focus is on ensuring that the Web app functions similarly to the Desktop app.

If you haven't already contacted Microsoft, I can bring this matter up during one of the bi-weekly meetings I attend with them, to explore the possibility of having this issue resolved.

Generally, I'm on the side of making names and labels human-readable, but in this case, it might be worth it to abbreviate the param names to save space.

Do you have any insights on the expected gains from this? I assume this could be manually tested by modifying the CaaS JSON and applying encoding/gzipping techniques.

Alternatively, maintaining a CaaS link map with Excel/JSON as a database might be a viable solution. Another approach could be a server-side solution (perhaps an AdobeIO endpoint) that uses a hashmap to return the CaaS link based on an ID. However, this would require modifications to multiple modules that handle CaaS to accommodate the change, not to mention the additional hop the page would need to make before getting the CaaS cards.

[meganthecoder]

• RE Microsoft: I wasn't in that discussion so thanks for explaining. I synced with Derron and team, and we haven't created a ticket yet. If you could bring this up with Microsoft in your next meeting, that would be great! @jedjedjedM 's point that the industry standard allows for much longer links seems like a good case for Microsoft to increase their limit. We understand that this might not be a high priority for them though so we'll move forward with what changes we can make in milo.
• RE Param names: I did a small test (see my response to Sanjay), but I can do a test with all params to get more accurate numbers.
• RE Excel/IO: This is definitely a possibility but I'd prefer to exhaust all options first for performance reasons.

[nerrdo]

To Jed's point, I do think that there is a case to be made to Microsoft that imposing such a tight character limit seems arbitrary from the customer point of view. Given that the potential exists for much larger URLs, it hardly seems unreasonable to suggest they increase it. But as Sunil points out, we need to be prepared for the fact that we're most likely asking them to change it in two products, even though we only care about one of them.

[chrischrischris]

Other than microsoft fixing the issue, we'll always have problems when many filters and/or tags are used. Things that might help:

Low Effort:

1. When converting the state into the hash, all of the properties that are using default values could be removed first.
2. Property names can be abbreviated in the state
3. Booleans can be converted to 0/1
4. Could aggregate properties into an array. E.g instead of having:

sortDateAsc: true,
sortDateDesc: true,
sortDateModified: false,
sortEnablePopup: true,
sortEnableRandomSampling: false,

we could do:

sortOpts: [1,1,0,1,0]

Medium Effort:

1. Similar to what @sanrai suggested: Instead of converting the gzipped data to a base64 string, convert it to a unicode string instead.
   This is somewhat non-standard, but all modern browsers support unicode characters so I don't think it'd be a problem.
   We'd use something similar to:

function arrayBufferToUnicodeString(buffer) {
    const uint16Array = new Uint16Array(buffer);
    let unicodeString = '';
    for (let i = 0; i < uint16Array.length; i++) {
        unicodeString += String.fromCharCode(uint16Array[i]);
    }
    return unicodeString;
}

function unicodeStringToArrayBuffer(unicodeString) {
    const uint16Array = new Uint16Array(unicodeString.length);
    for (let i = 0; i < unicodeString.length; i++) {
        uint16Array[i] = unicodeString.charCodeAt(i);
    }
    return uint16Array.buffer;
}

The unicode string would then have to be added to the url as a hash manually and NOT using new URL since that will encode the string
Quick tests show a nearly 2/3 length reduction of the string.
Issues: Need to make sure this will work in major browsers. I just did a quick test and am not 100% sure it will work for all data yet

High Effort:

1. Have the backend use id's for tags and filters so that we don't have to use the full string everytime they are specified. This will require backend changes as well as a way to look up the id/tag mapping (only for the configurator)

[meganthecoder]

We'll start with low effort item 1 removing defaults and see where that gets us https://jira.corp.adobe.com/browse/MWPW-158480

[meganthecoder]

Update: Removing defaults reduces most of our Batch 2 use cases enough except for the longest one (2940 characters on the main resource page), so we'll need something else as well. I tried low effort # 3, but that didn't change the length at all. I'll continue to try out these options and see what works.

[meganthecoder]

Update: Uint16Array didn't work for me.

As I understand it, Uint16Array stores 2 bytes per element, so the data inputted must be an even number of bytes or it will cause an error RangeError: byte length of Uint16Array should be a multiple of 2. I produced this error many times by changing the content in the config. Whether or not it errored depended on the length of the options authored. Additionally, I tried forcing an even array length, but that didn't work. @chrischrischris Let me know if I've missed something here that could make this work.

Looking at lists of binary-to-text encoding, it looks like Base85, suggested by @sanrai, is a little more efficient than Base64 (25% increase vs 33% increase), so I'll look into that next.

[sharmrj]

I'm curious: Which input causes the RangeError?

Since we don't care about actually representing utf-16 strings, just encoding them, utf-8 representations should be fine. You could try one of the following:

// ASCII only
Uint8Array.from(Array.from(text).map(letter => letter.charCodeAt(0)));
// equivalent-ish to above; it should be more reliable since it should encode UTF-16 -> UTF-8 properly
// It'll work with surrogate pairs and so on.
new TextEncoder().encode(text);
// charCodeAt should only give values between 0 and 65535, so it should be guaranteed to fit inside a 16bit word
Uint16Array.from(Array.from(text).map(letter => letter.charCodeAt(0)));
// codePointAt can give up to 32bits in some cases, since the space of all UTF-16 characters will actually exceed 2^16
// so sometimes we have surrogate pairs
Uint16Array.from(Array.from(text).map(letter => letter.codePointAt(0)));

[sanrai]

Hi @meganthecoder,

Here is the full implementation of converting switching from base64 to base 85.
https://gist.github.com/sanrai/8e320e44a0ed9966e5e1972069a2fc88

Adding this should cut your URL lengths on average by ~450 characters (check above gist).

This plus adding brotli compression as suggested above should help cut it down even further.

Below is the high level idea for why this algorithm works case you run into any issues or would like to make any further enhancements.

For str='easy':

Step 1: Convert to ASCII values e = 101 a = 97 s = 115 y = 121
Step 2: Combine into a single large number (101 * 256^3) + (97 * 256^2) + (115 * 256^1) + (121 * 256^0) = 1,701,012,089

Encode this number in Base64 and Base85 to get the specified output.

Base64 Encoding:

Divide by 64 repeatedly: 

- 1701012089 / 64 = 26578313 remainder 57. 
- 26578313 / 64 = 415286 remainder 9. 
- 415286 / 64 = 6488 remainder 54. 
- 6488 / 64 = 101 remainder 24. 
- 101 / 64 = 1 remainder 37 1 / 64 = 0 remainder 1.

Look up remainders in Base64 table (in reverse order): 1 = Z 37 = W 24 = F 54 = z 9 = e 57 = Q

Result: ZWFzeQ
Add padding: Since the original data is 4 bytes, we need to add two padding characters ('=') to make the length a multiple of 4.
Final Base64 result: ZWFzeQ==

Base85 Encoding:

Divide by 85 repeatedly: 

- 1701012089 / 85 = 20011907 remainder 4. 
- 20011907 / 85 = 235434 remainder 32. 
- 235434 / 85 = 2769 remainder. 59 
- 2769 / 85 = 32 remainder 59. 
- 32 / 85 = 0 remainder 32.

Look up remainders in Base85 table (in reverse order): 32 = A 59 = R 59 = T 32 = Y 4 = *
Final Base85 result: ARTY*

Comparing the results:

Base64 encoded: ZWFzeQ== 
Base85 encoded: ARTY*
Base64 length: 8 (including padding) 
Base85 length: 5
Size reduction: (1 - 5/8) * 100 = 37.50%

This gain is always guaranteed to be the case as Base85 is more efficient than Base64.

Base85 represents 4 bytes of binary data with 5 ASCII characters, whereas Base64 uses 4 characters for 3 bytes.

This results in about a 20% size reduction compared to Base64.

Some additional notes:

The sample config I used is much more complex and has many more edge cases than anything that an author could possibly set up inside BACOM (so the implementation should be very robust)

• Double and Triple Byte Characters (Unicode): The code can handle double and triple characters in the config correctly, ensuring that the encoding and decoding functions handle Unicode correctly.
• Attached config has sample text in Korean, Chinese, Russian, Thai, Japanese and English
• Configs with Link Transformations and regexes
• Custom HTML Card Injections
• Custom Sort Injections

For the page you are having issues w/ (the main resource page w/ 2940 characters), an authoring fix would be to use automatic filters versus custom filters (as using custom filters adds a lot of bloat to the config).

That should also cut about ⅓ of the characters in the URL.

Good luck!

[meganthecoder]

@sanrai I was running into issues trying to integrate your code into the caas configurator. The issue appears to be that Base85 uses unsafe URL characters (">%`^), and we're using code that escapes these characters (URL object, outerHTML, etc).

So you'd get this from your functions run by themselves:

+,^C)z!#&Y"5t_;7&;C.A]Q43EKT_h5p*OTqDrP1`4)>"5-6s8I,5udX96K"<_"WSE2tN"oZW->T`3=Kd#mQ55+%a/a[n&mE&QWu7A[&3Lea*.<QXd\\HR7dum3mJa?:%u/L6"+%t*a^4SSBGKQm,bbM6\'k-JDFjT"\\6H?!CNf-r8ZHK][nKusJ)A7lYMiN-@b8no*Q*>8+=@D]o=Q/s9_^A>;$u]JdRuY>(=*LFE"W5ap5kIN(@UkNq@DTK(W$Z>NaMkf!!

But you'd get this when copied from the configurator:
(Note that the " has now been encoded to %22)

+,^C)z!#&Y%225t_;7&;C.A]Q43EKT_h5p*OTqDrP1%604)%3E%225-6s8I,5udX96K%22%3C_%22WSE2tN%22oZW-%3ET%603=Kd#mQ55+%a/a[n&mE&QWu7A[&3Lea*.%3CQXd\HR7dum3mJa?:%u/L6%22+%t*a^4SSBGKQm,bbM6'k-JDFjT%22\6H?!CNf-r8ZHK][nKusJ)A7lYMiN-@b8no*Q*%3E8+=@D]o=Q/s9_^A%3E;$u]JdRuY%3E(=*LFE%22W5ap5kIN(@UkNq@DTK(W$Z%3ENaMkf!!

The escaped base85 string is longer than the base64 (332 vs 319), so it wouldn't be useful implementing it with escaped characters.

I could look into changing the code so that the URL never gets escaped, but that seems risky. Those characters are considered unsafe for a reason, right?

CC @chrischrischris

[meganthecoder]

Update: I replaced the URL object and outerHTML code that was escaping stuff, just to see, and some of those special characters do cause us issues. The quotes and angle brackets interfere with the anchor tag that we construct to be copied and pasted into the Word doc

The above hash output turns into:

<a href="http://localhost:3000/tools/caas#+++,^C)z!#&Y" 5t_;7&;C.A]Q43EKT_h5p*OTqDrP1`4) > 
"5-6s8I,5udX96K"<_"WSE2tN"oZW->T`3=Kd#mQ55+%a/a[n&mE&QWu7A[&3Lea*.<QXd\HR7dum3mJa?:%u/L6"+%t*a^4SSBGKQm,bbM6'k-JDFjT"\6H?!CNf-r8ZHK][nKusJ)A7lYMiN-@b8no*Q*>8+=@D]o=Q/s9_^A>;$u]JdRuY>(=*LFE"W5ap5kIN(@UkNq@DTK(W$Z>NaMkf!!">Content as a Service v3 - Tuesday, October 1, 2024 at 15:23
</a>

Where http://localhost:3000/tools/caas#+++,^C)z!#&Y is the href.

[sanrai]

Hi @meganthecoder,

We don't have to use any of these characters: ">%^ when encoding/decoding -- we can choose any 85 characters.

Since each integer represents a character, we can just define an array of 85 characters that are URL safe and encode/decode that way.

We then just map each int to our char array and we are fine.

The below updated code works and should be able to be used safely in word.
https://gist.github.com/sanrai/128cf8091b8659dd883eac5e5d9a86fa

I added some pretty difficult test cases as well to check for lots of various edge cases.

I also had some test code to verify the chars in our array won't be URLencoded (and guaranteed not to add any extra bytes) but I omitted it from the gist as it's trivial to validate.

Note: If you do happen to find any characters that are causing you issues, you can always just swap it out in the array at the top for another one.

[meganthecoder]

I've decided not to pursue this option any further for now.

I implemented Sanjay's code (branch), and the apostrophe was getting percent encoded, which brought up the number of characters. In the end, the reduction wasn't going to be enough on its own to get under the MS limit (only -4% on my longest link), so it wasn't worth continuing for this use case.

[chrischrischris]

Could use even more characters - Base256 Encoding:
Here's a c++ example that could be ported: https://github.com/fleschutz/base256

[sanrai]

@chrischrischris Base 256 could produce non-printable/invalid characters (since you are indexing character codes that are out of bounds) so it's potentially very dangerous to use on the web.

That's why Adobe PostScript, PDF and Github binary diffs stop at base85 (and partially why by convention base64 is used)
https://en.wikipedia.org/wiki/Ascii85

[sanrai]

Hi @meganthecoder,

Here is another potential solution that solves this problem and is significantly simpler than the base85 approach and gives more gain:
https://gist.github.com/sanrai/b523fe4ac38bdbbfe73d59066ca130d6

This alone should solve your problem and you should be able to keep the majority of the original Milo implementation in place and not have to worry about encoding issues.

If you want more compression than this, you can add base85 but I think it's overkill.

Solution: Use Dynamic Key Mapping

Objective: Reduce the size of the JSON configuration string by replacing long property names (keys) with shorter ones before compression and encoding.

We traverse the configuration object to collect all unique keys used at any level in the object and swap to use this mapping.

Original Key	Short Key
"andLogicTags"	'a'
"intraTagLogic"	'b'
"andTags"	'c'
"cardStyle"	'd'
"endpoint"	'e'
"excludeTags"	'f'
"excludedCards"	'g'
"contentId"	'h'
"layoutType"	'i'
...	...
"customFilterTag"	'aa'
"filtersCustomLabel"	'ab'

Results

Config: {"andLogicTags":[{"intraTagLogic":"OR","andTags":["caas:content-type/report","caas:content-type/video","caas:content-type/webinar","caas:content-type/infographic","caas:content-type/ebook","caas:content-type/guide","caas:content-type/demo","caas:content-type/blog","caas:content-type/customer-story","caas:content-type/event-session","caas:content-type/demos-and-videos","caas:content-type/podcast","caas:content-type/customer-blog"]}],"cardStyle":"1:2","endpoint":"14257-chimera.adobeioruntime.net/api/v1/web/chimera-0.0.1/collection","excludeTags":["caas:events/max","caas:content-type/product"],"excludedCards":[{"contentId":"64c7ad2e-7bf1-5e7f-8619-c66f27371445"},{"contentId":"0dfd22b4-56d1-5ce5-ad6e-b58c5ef608d5"},{"contentId":"d69bc403-58d5-5fcf-9fad-4d006f6b96d9"},{"contentId":"bfc32f06-6e6a-5f99-b252-48c1410be5a3"},{"contentId":"c80d9edd-8c6d-5fc2-97f1-445f53e49188"},{"contentId":"97380bce-0678-5e02-900e-82957e2c4afe"}],"layoutType":"3up","loadMoreBtnStyle":"over-background","paginationEnabled":true,"paginationQuantityShown":true,"paginationUseTheme3":true,"placeholderUrl":"https://main--bacom--adobecom.hlx.live/caas/mappings","resultsPerPage":"9","searchFields":["overlays.banner.description","contentArea.description","contentArea.detailText","contentArea.title","overlays.label.description"],"setCardBorders":true,"showFilters":true,"showSearch":true,"showTotalResults":true,"sortEnablePopup":true,"source":["bacom"],"totalCardsToShow":"4500","filters":[{"filterTag":["caas:products"],"openedOnLoad":"","icon":"","excludeTags":["caas:products/magento-commerce"]},{"filterTag":["caas:content-type"],"openedOnLoad":"","icon":"","excludeTags":["caas:content-type/customer-story"]},{"filterTag":["caas:topic"],"openedOnLoad":"","icon":"","excludeTags":["caas:topic/enterprise-work-management"]},{"filterTag":["caas:industry"],"openedOnLoad":"","icon":"","excludeTags":[]}],"sortDateAsc":true,"sortDateDesc":true,"sortTitleAsc":true,"sortTitleDesc":true,"collectionName":"All resources","doNotLazyLoad":true,"autoCountryLang":true,"showIds":true,"filterBuildPanel":"custom","filtersCustom":[{"filterTag":"","openedOnLoad":"","icon":"","excludeTags":"","group":"{customGroupA}","filtersCustomItems":[{"filtersCustomLabel":"Advertising","customFilterTag":["caas:products/adobe-advertising-cloud"]},{"filtersCustomLabel":"Analytics","customFilterTag":["caas:products/adobe-analytics"]},{"filtersCustomLabel":"Audience Manager","customFilterTag":["caas:products/adobe-audience-manager"]},{"filtersCustomLabel":"Campaign","customFilterTag":["caas:products/adobe-campaign"]},{"filtersCustomLabel":"Commerce","customFilterTag":["caas:products/adobe-commerce"]},{"filtersCustomLabel":"Customer Journey Analytics","customFilterTag":["caas:products/customer-journey-analytics"]},{"filtersCustomLabel":"Experience Manager Assets","customFilterTag":["caas:products/adobe-experience-manager-assets"]},{"filtersCustomLabel":"Experience Manager Forms","customFilterTag":["caas:products/adobe-experience-manager-forms"]},{"filtersCustomLabel":"Experience Manager Guides","customFilterTag":["caas:products/experience-manager-guides"]},{"filtersCustomLabel":"Experience Manager Sites","customFilterTag":["caas:products/adobe-experience-manager-sites"]},{"filtersCustomLabel":"GenStudio","customFilterTag":["caas:products/genstudio"]},{"filtersCustomLabel":"Journey Optimizer","customFilterTag":["caas:products/adobe-journey-optimizer"]},{"filtersCustomLabel":"Journey Optimizer B2B Edition","customFilterTag":["caas:products/adobe-journey-optimizer-b2b-edition"]},{"filtersCustomLabel":"Learning Manager","customFilterTag":["caas:products/learning-manager"]},{"filtersCustomLabel":"Marketo Engage","customFilterTag":["caas:products/marketo-engage-bizible"]},{"filtersCustomLabel":"Mix Modeler","customFilterTag":["caas:products/adobe-mix-modeler"]},{"filtersCustomLabel":"Product Analytics","customFilterTag":["caas:products/adobe-product-analytics"]},{"filtersCustomLabel":"Real-Time CDP","customFilterTag":["caas:products/adobe-real-time-cdp"]},{"filtersCustomLabel":"Target","customFilterTag":["caas:products/adobe-target"]},{"filtersCustomLabel":"Workfront","customFilterTag":["caas:products/workfront"]}]},{"filterTag":"","openedOnLoad":"","icon":"","excludeTags":"","group":"{customGroupB}","filtersCustomItems":[{"filtersCustomLabel":"{customFilterB1}","customFilterTag":["caas:content-type/blog"]},{"filtersCustomLabel":"{customFilterB2}","customFilterTag":["caas:content-type/customer-story"]},{"filtersCustomLabel":"{customFilterB3}","customFilterTag":["caas:content-type/demo"]},{"filtersCustomLabel":"{customFilterB4}","customFilterTag":["caas:content-type/demos-and-videos"]},{"filtersCustomLabel":"{customFilterB5}","customFilterTag":["caas:content-type/ebook"]},{"filtersCustomLabel":"{customFilterB6}","customFilterTag":["caas:content-type/event-session"]},{"filtersCustomLabel":"{customFilterB7}","customFilterTag":["caas:content-type/guide"]},{"filtersCustomLabel":"{customFilterB8}","customFilterTag":["caas:content-type/infographic"]},{"filtersCustomLabel":"{customFilterB9}","customFilterTag":["caas:content-type/podcast"]},{"filtersCustomLabel":"{customFilterB10}","customFilterTag":["caas:content-type/report"]},{"filtersCustomLabel":"{customFilterB11}","customFilterTag":["caas:content-type/video"]},{"filtersCustomLabel":"{customFilterB12}","customFilterTag":["caas:content-type/webinar"]}]},{"group":"{customGroupC}","filtersCustomItems":[{"filtersCustomLabel":"{customFilterC1}","customFilterTag":["caas:industry/automotive-&-mobility"]},{"filtersCustomLabel":"{customFilterC2}","customFilterTag":["caas:industry/consumer-goods"]},{"filtersCustomLabel":"{customFilterC3}","customFilterTag":["caas:industry/financial-services"]},{"filtersCustomLabel":"{customFilterC4}","customFilterTag":["caas:industry/government"]},{"filtersCustomLabel":"{customFilterC5}","customFilterTag":["caas:industry/healthcare"]},{"filtersCustomLabel":"{customFilterC6}","customFilterTag":["caas:industry/high-tech"]},{"filtersCustomLabel":"{customFilterC7}","customFilterTag":["caas:industry/manufacturing"]},{"filtersCustomLabel":"{customFilterC8}","customFilterTag":["caas:industry/media-and-entertainment"]},{"filtersCustomLabel":"{customFilterC9}","customFilterTag":["caas:industry/public-sector"]},{"filtersCustomLabel":"{customFilterC10}","customFilterTag":["caas:industry/retail"]},{"filtersCustomLabel":"{customFilterC11}","customFilterTag":["caas:industry/telecommunications"]},{"filtersCustomLabel":"{customFilterC12}","customFilterTag":["caas:industry/travel-and-hospitality"]}],"openedOnLoad":""}],"hideDateInterval":true}
Key Map: {andLogicTags: 'a', intraTagLogic: 'b', andTags: 'c', cardStyle: 'd', endpoint: 'e', …}
Mapped Base64 encoded length: 1792 characters
Mapped Base64 encoded string: H4sIAAAAAAAAE5VXTXPbNhD9KxocehIkiiIpkTdbcdymdZNJMtNDxgcQWFKISYAFQVlKxv+9A34psggkPWk1+97DAvsAAt8RQcmX7yhFCXr/Ec0RRckXRAmpEyqFBqGxPlWwVFBJpU3+KnXgDORk5hlSLoiazHGRyVyRas/pZB5SKZ8mM3nDGUxmGJTThaSFzCcTtKm1LEHhWkt1mi7kYMIa6ppLYR22xkQw3C5FPQmqJKOknl7BsYq2zseXxzliKEGrxEdzBCYK/HCD6Z6XoMiCMJkCl6oRmpewEKCXpOLLw8os+LJHYW/hLVZLKosCqO5Kz8betpOqlyU5TherJGuoRo9zlLf22KMERQHdEOYD3qTZCoewyfA2WsWYRlHmb9abVRCE6GXegT2WMd9PAxxGbIVDCiEmLAKchlsaQhZ5W3YGsyhOaeCtcbhlIQ4zmuE4IwwHzPOiLErjiMUjOM3o2s+8CEcQERxmcYxTP/RxsKWrYOWlEJL1CKZbj8XAGN7SiBllH8ebbIWDIMzCNQTxarsdwfFmvfVSCtiLNlscgufj2PMAb/043IBPA5IBMs3hKEHrpkJz9BUlSB5M5wh9ypVsBENz9IQSrRqYo2IIyiEQKEF7ras6WS5LwgU2TFli3DaVynKxL46Lgh9gadqyLElVcZEbT0lTIpqjynTRDFqQU71IiRCgFgxqqnjVN7pv5o0C4sxowovPcNSvEprrwuywcZCCpFBcKD3O0b/DnNQQ1EOgh6AZgoMpup2qoT6jBAWh56E5Orb+Oo3O7K1XG9g3lCA0RzfdT3aFWZYkB6ElprIsQVFAj6aXp8kjzCXoOhNeSWpZcerSagFLEBpUpXgN+FmqJ1wSQXIoQejXglywptZmoCnN9jC4HVZxNwRvhuBuCN6iBN0UxUxBLRtFwTjmfkj+PgR/DME7sznaiaI5+nPogRn1qgbz8xdK0PcOf69kU928oDl6aGl/m4HZAZTmNRfmmH1/3ajW3ZicYZgWsmHdWrQKghQnzWnt5I+gM69hHASF2UO7wMpJ77F9M9RZZUfKivBcuNh0wJxZg+tcrAtntqzeXrN3slECTrOfTH2049cOP7UKd8cK1MU6zG7qGrRzNWEkDQuCSUdy6b6Vqvy/slnLcanem2+6RXZCMO/gLsVPXNsErXXWLWdUvQfxSTeMy2mZHETdpUfG0NL3leYl/+a249BPOYLtOrNb/3Z2x3h/iv+6Jk79FENPHPX/AqIEF7l71xQ96nq/PBD1BFrO7kROcov/yw6DocXglH/jafHDPnjgx9mDZFC4V6nkR1z2sJH7ocP8bOt0Cv3fqX3zEUiBP/MSZrs3H1waygDNbQtTVp35n4nKQbuIukOMjH+kesqUFBbS85h+fBm+E798KN9eHsp96i0vNKjb1cvFiNfX47HES57v4E19Ka8V1g6F9sZu4QU/4V1cuS0aoUOje2FYiJGLePEisAhsHALdC8ZC3DqIPz6aLPTYQR/eIBbqynNw+wegjeqyV/dAtDFdBhsekP1meG34ncPwu1cVDdesJWm0LKXmB8C/4VKmvODa5t2dbxGhUtSNcX4uJbO5b7e2sDMuiKCcFLgGdeAUrAqBRSE3V3Nxvk5eM0MLcw+k0HtKlM2Au8jG5Pkea6B7G3FjIZZENBmhulHmfmghb21kYJy0O729UmvCndOOLTJVkxac4hqolspGfr0BRrZqX0pWms1qGgrzpCsbwSkxX2Brn1/vgrOEIgco2vnvZV1xTXq7Dq8FE3zobvUv/wFOhxzOzREAAA==
Original Base64 encoded length: 2140 characters
Original Base64 encoded string: H4sIAAAAAAAAE61Yy3LjuA79FZcWszJj+SG/don7UT2VTGc67rqLqSwgEpJ5Q5EqknLiTuXfb1GSFduRVXTP3cUEcQ5BACcUXgOQ7FalnK4hNcHyn9eAS6thDWm5GiyD7z+CvttVbwgogFlSJS1KS+wux4HGXGkb9FtMW85QtVqeMeYSdKuNy0SlGvINp612jJV6arWkBWfYamGYtR8kFiptNdDCWJWhJsYqvWs/yNb9adAYruRZWkNAMlJehWndlCtGwbTfYHOK8pyPb49uk2YPdicwWAbD5SjoByhZrri0bmEyimaEbniGGq6AqRi50oW0PMMriXYAOR9sh+7+B/UuEl6FV8MBVUIgtVUk+EJFwfAo6WW0ZpDBS3sUWrGC2uCx8WYr0KyqqnrnNxYsg+mEzoCNkMziZEginCVkPh0uCJ1Ok9FsPBtOJlHw1j92ClnCRqN4QqIpG5KIYkSATZHE0ZxGmEzDOfvoxKaLmE7CMYnmLCJRQhOySICRCQvDaTKNF1O2+OAUJ3Q8SsIpmeIUSJQsFiQeRSMymdPhZBjGGMH4gxOdh2yBjJE5nTLHNCKLWTIkk0mURGOcLIbz+QenxWw8D2OKJJzO5iTCcEQWYYhkPlpEMxzRCSQYuIwL2KnCrne5S/m4yIN+IBSwO6Xxxsp9LaitKxOgT6lWhWRBP8gh5RJcSj9LiAWyYGl1gYeGvwuQltvdw0Y9y4/mnwbXG8xw3JgEUNwowVD/1CJYBhtrc7McDDLgkjh6lRFS1h1V2dVGvFwJvsWBq5dBBnnOZeq6QKMphDX3qO8hdadfBP3AIGi6+cJRlGVTRiRgZ65ikBL1FUNDNc/rGq2v8lojdFoscLHGF3tisNwKpxUNiYAYxRHSozuSdVV8ozRDbfa3YDbq+QsX9mTpoTz/4cpaWRA/qlibdaVtlY97lRf5+3KhKbqwy0t05NZ5l020Vi5BwTKYRGEY9INkT/7Pa/33GtKmU+tWNA5D5SiRfZe3ClzNBf2AUyWrv9q6fO87yCBFaRWhKsvQnezR1e9HskMR+B3CLtE9Q2lVzunvcJWOA5QWda65QfKs9BPJQEKKGUp7jpBLVhjrDnQJZ6nWLtufwOK1oYcF4JY+4fHa2lXkdcva4cZ3mf4LMtc410L0NFbV4zqLqb+UvYVfu+qAlRcUVq1UIa3e3YJMD0v0G2sqswr8puCC3YNE195VQt4rblX9Pqk7F7v3vbgFJ1F5sAxeK/yv7uf12ynNN4vZYY3Xy7euUV3kbIvacsNl+R+8tH052wyDUpQIvDsRKlTBDnN+SiBB7Cyn5gL4xqUDtmAcJcXeXVl4+gL02rMuWd1BsoIsB55Kf3C69+gA3WuBP2iLepyC1j3f+1MVWuKud9G1N4rx38rbKwOfX3LURznoXRuD9oJEYwOxTwaBCuIi2i9KZ/+ONSkRLiL96p7JXqwtfGnlfBHhA7d+fGejNCXCedKvKB9swbjyYUlRmmrzecB9MX7PLc/4r0u6dF+JqnG9gKZ3M7rpfWZ8/5T5TUoSj2KCNcx5+lsELblML5EiUft4iNAd6Ce0qvdZpu6V5wGeVR4ESw8S8188Fl3qccdfeneKobgkQxl/IVntdB76vnK6TI8qgvqnlxj9QBBkzTPsrT7d+1No5+Y+6whleQf8GnSK1h/XVvvPA/5H6adEK+mF+dxsfnw7fVz9X14NN5e+Gl4Pz3wzfOuI4uOg4PytHMOOvGHPv3g7CcbeBOXkwxd2chHs0WTDlyLypqjmPL64U3/co7GNL/7MG7+aQvnizr1xD+divugLb/T9FMoXeRh6Q9cTQm9k/6asBozewP5tuZ9P1qrVpjyrf6U8q84g9x+cA/fhlinLt0j+IJmKueDWWyVWnfE2HFRJUzgJSpVi3o286pSgBjzhEiTlIIhBveW08xV3TNApRg1B6gY48vTrvRO4U4Ia4A2CsBsK2ruXV50a9A7M0w2xSDfeuJ3a0+BmIIsEqC20+yL2xe7Un3dsZBxKuS+nJxb4ZVfeqUMNS17EglNikFrV9TI76aROJWrAdTkJ9Ef1a1CLwk06s0JyWo5M/eu7W47eGTRsUZR3v1Em5xZqDWgZRrm1DWfoxkvfXKK2IKrpztv/AKosJ3zsGQAA
Reduction in length: 348 characters (16.26%)
Decoding, decompression, and key unmapping successful: true

[meganthecoder]

We were able to update some of the content to get us under the limit for that last longest link. Woohoo!

I still think that shortening the param names is a decent idea though, so maybe we implement something like this in the future.

[meganthecoder]

Thanks for everyone's help and input on this! We've solved the immediate need for bacom for now and gotten the longest link down to 1968 characters. Yay!

What was implemented:

• Exclude defaults from caas links (caas config v3): MWPW-158480 Exclude defaults from caas links #2907 - Released
• Bacom content updates: remove unnecessary Excluded Card IDs - Ticket Created
• MS Design Change Request for desktop - Ticket creation in progress

That being said, it's still relatively close to the limit. If there are any changes to the config, we could find ourselves over the limit again and might need to reopen this discussion.

With that idea in mind, another option that we might consider for the future is to focus on reducing the filters specifically since bacom's custom filters add about 1450 characters themselves. We can't use automated filters to get what the PM wants as is, but maybe enhancements could be made in the future.