Expand my Community achievements bar.

SOLVED

Campaign Query Parameters with Colons

Avatar

Level 2

Hello,

I had a question regarding campaign query parameters. I am designing them as one string for the campaign variable www.test.com?ecid=test:test:test for example.

Would you consider a colon a url safe character?  I would like to understand because I thought the colon approach was url safe for the appended campaign parameters.

Thanks,

Tim

1 Accepted Solution

Avatar

Correct answer by
Level 5

Your vendor probably meant that colons aren't great to use in URLs because they are part of RFC 3986's reserved characters, since colon has a special meaning in the URL.

Technically, since colon has no special meaning as part of the URL query string, they don't need to be URL-encoded. However, Firefox is strict, and URL-encodes it anyway when typed /pasted into the address bar.

What's more, if your marketer is building and testing the URL in Firefox, and copies it from the address bar, it will preserve that encoding, so now if they paste it into a page, all users will come through with %3A.

So, it's not totally safe to use colons - they may come through in a couple of different formats.

View solution in original post

8 Replies

Avatar

Community Advisor

we use it as you described and had no problems so far.

Avatar

Employee Advisor

I have seen colons being used too. And are safe to be used in a query value according to the URL format rules.

Are you having any issues?

Avatar

Level 3

The colon would help us to segregate the value which come from the different market (from third party web site) like

?ecid=Google:5008500:ABCSite:Active. As per your URL it will track fine think so. You can refer the same value from the allotted conversion variable (Evar).

Avatar

Level 2

We used to use a colon, but recently switched to a pipe. We had too many instances where an author would use a colon for something else, such as a subject line and screw up our tracking. We haven't seen errant pipes...yet.

Avatar

Community Advisor

TLDR;

Yes, you may use the colon character, ":" as a general delimiter within the query component of a URI.

===============================================

http://www.ietf.org/rfc/rfc3986.txt

2.2. Reserved Characters

  URIs include components and subcomponents that are delimited by

  characters in the "reserved" set. These characters are called

  "reserved" because they may (or may not) be defined as delimiters by

  the generic syntax, by each scheme-specific syntax, or by the

  implementation-specific syntax of a URI's dereferencing algorithm.

  If data for a URI component would conflict with a reserved

  character's purpose as a delimiter, then the conflicting data must be

  percent-encoded before the URI is formed.

  reserved = gen-delims / sub-delims

  gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

  sub-delims = "!" / "$" / "&" / "'" / "(" / ")"

  / "*" / "+" / "," / ";" / "="

  The purpose of reserved characters is to provide a set of delimiting

  characters that are distinguishable from other data within a URI.

  URIs that differ in the replacement of a reserved character with its

  corresponding percent-encoded octet are not equivalent. Percent-

  encoding a reserved character, or decoding a percent-encoded octet

  that corresponds to a reserved character, will change how the URI is

  interpreted by most applications. Thus, characters in the reserved

  set are protected from normalization and are therefore safe to be

  used by scheme-specific and producer-specific algorithms for

  delimiting data subcomponents within a URI.

  A subset of the reserved characters (gen-delims) is used as

  delimiters of the generic URI components described in Section 3. A

  component's ABNF syntax rule will not use the reserved or gen-delims

  rule names directly; instead, each syntax rule lists the characters

  allowed within that component (i.e., not delimiting it), and any of

  those characters that are also in the reserved set are "reserved" for

  use as subcomponent delimiters within the component. Only the most

  common subcomponents are defined by this specification; other

  subcomponents may be defined by a URI scheme's specification, or by

  the implementation-specific syntax of a URI's dereferencing

  algorithm, provided that such subcomponents are delimited by

  characters in the reserved set allowed within that component.

3. Syntax Components

  The generic URI syntax consists of a hierarchical sequence of

  components referred to as the scheme, authority, path, query, and

  fragment.

  URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

Avatar

Level 2

Yes I had a vendor tell us we were using unsafe characters for www.test.com?ecid=test:test:test on their email system (They add their own tracking and its conflicting with our parameters)


I was surprised they thought colons were unsafe. Since I have learned about them since I started in marketing. I'm glad I have the support of this forum to back up that colons are a good practice for campaign query parameters.

Avatar

Correct answer by
Level 5

Your vendor probably meant that colons aren't great to use in URLs because they are part of RFC 3986's reserved characters, since colon has a special meaning in the URL.

Technically, since colon has no special meaning as part of the URL query string, they don't need to be URL-encoded. However, Firefox is strict, and URL-encodes it anyway when typed /pasted into the address bar.

What's more, if your marketer is building and testing the URL in Firefox, and copies it from the address bar, it will preserve that encoding, so now if they paste it into a page, all users will come through with %3A.

So, it's not totally safe to use colons - they may come through in a couple of different formats.

Avatar

Community Advisor

Hi see this thread.

Adobe adding some symbols to campaign name

The colons work but what you will find as Click through links are populated and re-shared it may cause you issues. Especially with banner links that may be re encoded via social links...

i have found "_" "underscore" to be a safer alternative. also works better for secondary sharing etc.