1 person found this helpful
we use it as you described and had no problems so far.
1 person found this helpful
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?
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).
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.
2 people found this helpful
Yes, you may use the colon character, ":" as a general delimiter within the query component of a URI.
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
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
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.
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.
Hi see this thread.
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.