Rules & Filtering
Introduction
Products utilizing PowerTrack rules deliver social data to you based on filtering rules you set up. Rules are made up of one or more ‘clauses’, where a clause is a keyword, exact phrase, or one of the many PowerTrack operators. Before beginning to build PowerTrack rules, be sure to review the syntax described below, look through the list of available operators, and understand the restrictions around building rules. You should also be sure to understand the nuances of how rules are evaluated logically, in the ‘order of operations’ section.
Multiple clauses can be combined with both ‘and’ and ‘or’ logic. ‘And’ logic is specified with a space between clauses, and ‘or’ logic is specified with an upper-case OR. See below for more details…
PowerTrack rule format:
- Each rule can be up to 2,048 characters long with no limits on the number of positive clauses (things you want to match or filter on) and negative clauses (things you want to exclude and not match on).
New Operators
- url: (tokenized matching on url)
- url_title: (tokenized match on expanded URL HTML Title)
- url_description: (tokenized match on expanded URL HTML Description) For more see our URL enhancement here
- bio: (a tokenized match on the contents of a user’s bio string)
- bio_name: (a tokenized match on the contents of a user’s “Name” field)
- place_country: Replaces version 1.0 country_code Operator.
- profile_country: Replaces version 1.0 profile_country_code Operator.
- has:images (returns all tweets that contain native images (e.g. pic.twitter.com))
- has:videos (returns all tweets that contain native videos (does not include vine, periscope))
- is:quote (returns all quoted tweets)
Operators that Match Quote Tweets
In terms of filtering, the operators below will match on content from both the original quoted Tweet and the new “comment” Tweet.
- Keywords
- Phrases
- Proximity
- #hashtags
- @mentions
- $cashtags
- url:
- url_contains:
- has:links
- has:mentions
- has:hashtags
- has:media
- has:symbols
- is:quote
Building Rules with PowerTrack
Keyword match
Keyword matches are similar to queries in a search interface (e.g. Google). For example, the following PowerTrack rule would match activities with ‘happy’ in the text body.
happy
ANDing terms with white space
Adding another keyword is the same as adding another requirement for finding matches. For example, this rule would only match activities where both ‘happy’ and ‘party’ were present in the text, in either order – having a space between terms operates as boolean AND logic. If you include an explicit AND in your rule, it will rejected by the rules endpoint.
happy party
ORing terms with upper-case OR
Many situations actually call for boolean OR logic, however. This is easily accomplished as well. Note that the OR operator must be upper-case and a lower-case ‘or’ will be treated as a regular keyword.
happy OR party
Negating terms
Still other scenarios might call for excluding results with certain keywords (a boolean NOT logic). For instance, activities with ‘happy’, but excluding any with ‘birthday’ in the text.
happy -birthday
Grouping with parentheses
These types of logic can be combined using grouping with parentheses, and expanded to much more complex queries.
(happy OR party) (holiday OR house) -(birthday OR democratic OR republican)
This is just the beginning though – while the above examples rely simply on tokenized matching for keywords, PowerTrack also offers a operators to perform different types of matching on the text.
Exact match
"happy birthday"
Substring match
contains:day
Proximity match
"happy birthday"~3
Further, other operators allow you to filter on unique aspects of social data, besides just the text. For example:
The user who is posting a Tweet
from:user
Geo-tagged Tweets within 10 miles of Pearl St. in Boulder, CO
point_radius:[-105.27346517 40.01924738 10.0mi]
Putting it all together
These can be combined with text filters using the same types of logic described above.
(happy OR party) (holiday OR house OR "new year's eve") point_radius:[-105.27346517 40.01924738 10.0mi] lang:en -(birthday OR democratic OR republican)
Boolean Syntax
The examples in the previous section, utilized various types of boolean logic and grouping. See the table below for additional detail regarding the syntax and requirements for each.
| Logic Type | PowerTrack Syntax | Description |
|---|---|---|
| AND | social data |
Whitespace between two operators results in AND logic between them Matches activities containing BOTH keywords ('social', 'data'). Do NOT use AND explicitly in your rule. Only use whitespace. An explicit AND will be treated like a regular keyword. |
| OR | social OR data |
To OR together two operators, insert an all-caps OR, enclosed in whitespace between them Matches activities with EITHER keyword ('social' OR 'data') Note that if you combine OR and AND functionality in a single rule, you should understand the order of operations described here, and consider grouping operators together using parentheses as described below to ensure your rule behaves as expected. You must use upper-case 'OR' in your rule. Lower-case 'or' will be treated as a regular keyword. |
| NOT | social -data apple -(fruit OR orange) apple -(android phone) |
Insert a - character immediately in front of the operator or group of operators. The example rule shown matches activities containing keyword 'social', but excludes those which contain the keyword 'data') Negated ORs are not allowed where the rule would request "everything in the firehose except the negation." E.g., apple OR -ipad is invalid because it would match all activities except those mentioning 'ipad'. |
| Grouping | (social OR data) -(gnop OR ping) |
Parentheses around multiple operators create a functional "group". Groups can be connected to clauses in the same manner as an individual clause via whitespace (AND) or ORs, and can be negated. However, note that the same restriction described above regarding negation/OR combination also applies to groups. For example, the following are examples of invalid syntax using groups: ipad OR -(iphone OR ipod) ipad OR (-iphone OR ipod) Grouping is especially important where a single rule combines AND and OR functionality, due to the order of operations used to evaluate the rule. See below for more details. |
Note that operators may be either positive or negative.
Positive Operators define what you want to include in the results. E.g. the ‘has:hashtags’ operator says “I want activities containing hashtags.”
Negative Operators define what you want to exclude from the results, and are created by using the Boolean NOT logic described above. E.g. ‘-has:hashtags’ says “Exclude any activities containing hashtagss, even if they otherwise match my rule.”
PowerTrack has no restriction on the number of positive and negative clauses, subject to a maximum length of 2,048 characters.
Order of Operations
When combining AND and OR functionality in a single rule, the following order of operations will dictate how your rule is evaluated.
- Operators connected by AND logic are combined first
- Then, operators connected with OR logic are applied
Example:
- apple OR iphone ipad would be evaluated as apple OR (iphone ipad)
- ipad iphone OR android would be evaluated as (iphone ipad) OR android
To eliminate uncertainty and ensure that your rules are evaluated as intended, group terms together with parentheses where appropriate. For example:
- (apple OR iphone) ipad
- iphone (ipad OR android)
Punctuation, Diacritics, and Case Sensitivity
Also see Restrictions below.
If you specify a keyword or hashtag rule with character accents or diacritics for PowerTrack, it will match Tweet text honoring the diacritics (hashtags or keywords). Rule with a keyword Diacrítica or hashtag #cumpleaños will match Diacrítica or #cumpleaños but not Diacritica or #cumpleanos without the tilde í or eñe.
Characters with accents or diacritics are treated the same as normal characters and are not treated as word boundaries. For example, a rule of cumpleaños would only match activities containing the word cumpleaños and would not match activities containing cumplea, cumplean, or os.
All operators are evaluated in a case-insensitive manner. For example, the rule Cat will match all of the following: cat, CAT, Cat.
Rule Tags
As described here, each rule may be created with a tag. These tags have no effect on filtering, but can be used to create logical groupings of rules within your app. Each rule may have only one tag, with a maximum of 255 characters. Tags are included with the JSON formatted rule at the time of creation via the API, as described in our documentation.
Putting Rules in JSON Format
In order to add or delete a rule from a PowerTrack stream via the API, the rules must utilize JSON format. Essentially, this requires putting each rule into the following structure:
{"value":"insert_rule_here"}
Rules with Double-quotes
If the ‘rule’ contains double-quote characters (“) associated with exact-match or other operators, they must be escaped using a backslash to distinguish them from the structure of the JSON format. For example, if your rule is:
"social data" @gnip
The JSON formatted rule would be:
{"value":"\"social data\" @gnip"}
Rules with Double-quote String Literals
To include a double-quote character as a string literal within an exact-match, it must be double-escaped. For example, for a rule matching on the exact phrase ‘Toys “R” Us’, including the double-quotes around R, the plain-text representation of this would look like the following:
"Toys \"R\" Us"
Translating this to JSON format, you should use the following structure:
{"value":"\"Toys \\\"R\\\" Us\""}
Rules with Tags
To include an optional Tag with your rule, as described above, simply include an additional “tag” field with the rule value:
{"value":"\"social data\" @gnip","tag":"RULE-TAG-01"}
Formatting for API Requests
When adding or deleting rules from the PowerTrack stream via the API, multiple JSON formatted rules should be comma delimited, and wrapped in a JSON “rules” array, as shown below:
{"rules":[{"value":"from:gnip"},{"value":"\social data\" @gnip","tag":"RULE-TAG-01"}]}
List of Operators
Below is a list of all operators supported in PowerTrack. Note that while many operators work across multiple different data sources, others are specific to a specific source. See the Sources column for the data sources that a specific operator applies to.
| Operator | Description | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
keyword |
Matches a keyword within the body of an activity. This is a tokenized match, meaning that your keyword string will be matched against the tokenized text of the activity body – tokenization is based on punctuation, symbol, and separator Unicode basic plane characters. For example, an activity with the text “I like coca-cola” would be split into the following tokens: I, like, coca, cola. These tokens would then be compared to the keyword string used in your rule. To match strings containing punctuation (e.g. coca-cola), symbol, or separator characters, you must use a quoted exact match as described below.
|
||||||||||||||||||||||||
emoji |
Matches an emoji within the body of an activity. Emojis are a tokenized match, meaning that your emoji will be matched against the tokenized text of the activity body – tokenization is based on punctuation, symbol/emoji, and separator Unicode basic plane characters. For example, an activity with the text “I like 🍕” would be split into the following tokens: I, like, 🍕. These tokens would then be compared to the emoji used in your rule. Note that if an emoji has a variant, you must use “quotations” to add to a rule.
|
||||||||||||||||||||||||
"exact phrase match" |
Matches an exact phrase within the body of an activity. This is an exact match, and it is not necessary to escape characters with a backslash. For example, if matching something with a slash, use “one/two”, not “one\/two”. Note that this is not a substring match, and includes a check for word boundaries at the ends of the quoted phrase. For a pure substring match, see the contains: operator below.
|
||||||||||||||||||||||||
"keyword1 keyword2"~N |
Commonly referred to as a proximity operator, this matches an activity where the keywords are no more than N tokens from each other. If the keywords are in the opposite order, they can not be more than N-2 tokens from each other. Can have any number of keywords in quotes. N cannot be greater than 6.
|
||||||||||||||||||||||||
contains: |
Substring match for activities that have the given substring in the body, regardless of tokenization. In other words, this does a pure substring match, and does not consider word boundaries. Use double quotes to match substrings that contain whitespace or punctuation.
|
||||||||||||||||||||||||
from: |
Matches any Tweet from a specific user. The value must be the user’s Twitter numeric Account ID or username (excluding the @ character). See HERE or HERE for methods for looking up numeric Twitter Account IDs.
|
||||||||||||||||||||||||
to: |
Matches any Tweet that is in reply to a particular user. The value must be the user’s numeric Account ID or username (excluding the @ character). See HERE for methods for looking up numeric Twitter Account IDs.
|
||||||||||||||||||||||||
url: |
Performs a tokenized (keyword/phrase) match on the expanded URLs of a tweet (similar to url_contains).
|
||||||||||||||||||||||||
url_title: |
Performs a keyword/phrase match on the (new) expanded URL HTML title metadata.
|
||||||||||||||||||||||||
url_description: |
Performs a keyword/phrase match on the (new) expanded page description metadata.
|
||||||||||||||||||||||||
url_contains: |
Matches activities with URLs that literally contain the given phrase or keyword. To search for patterns with punctuation in them (i.e. google.com) enclose the search term in quotes. NOTE: If you’re using Gnip’s Enriched output format, we will match against Gnip’s expanded URL as well.
|
||||||||||||||||||||||||
has:links |
This operators matches activities which contain links in the message body.
|
||||||||||||||||||||||||
sample: |
Returns a random sample of activities that match a rule rather than the entire set of activities. Sample percent must be represented by an integer value between 1 and 100. This operator applies to the entire rule and requires any “OR’d” terms be grouped. Important Note: The sample operator first reduces the scope of the firehose to X%, which then the rest of the rule is applied to. Each Tweet individually (of all tweets) has a 10% chance of being in a 10% sample, or 1%chance:1%sample, 50%chance:50%sample, etc. The sample is applied before the rule is applied to the sample. Also, the sampling is deterministic, and you will get the same data sample in realtime as you would if you pulled the data historically.
|
||||||||||||||||||||||||
# |
Matches any activity with the given hashtag. This operator performs an exact match, NOT a tokenized match, meaning the rule “2016” will match posts with the exact hashtag “2016”, but not those with the hashtag “2016election” Note: that the hashtag operator relies on Twitter’s entity extraction to match hashtags, rather than extracting the hashtag from the body itself. The description of how Twitter extracts entities can be found here: http://dev.twitter.com/pages/tweet_entities.
|
||||||||||||||||||||||||
point_radius:[lon lat radius] |
Matches against the Exact Location (x,y) of the Activity when present, and in Twitter, against a “Place” geo polygon, where the Place is fully contained within the defined region.
|
||||||||||||||||||||||||
bounding_box:[west_long south_lat east_long north_lat] |
Matches against the Exact Location (x,y) of the Activity when present, and in Twitter, against a “Place” geo polygon, where the Place is fully contained within the defined region.
|
||||||||||||||||||||||||
@ |
Matches any Tweet that mentions the given username or userID The to: operator returns a subset match of the @mention operator. Note that the mention operator relies on Twitter’s entity extraction to match mentions, rather than trying to extract the mention from the body itself. The description of how Twitter extracts entities can be found here: http://dev.twitter.com/pages/tweet_entities.
|
||||||||||||||||||||||||
$ |
Matches any Tweet that contains the specified ‘cashtag’ (where the leading character of the token is the ‘$’ character). Note that the cashtag operator relies on Twitter’s ‘symbols’ entity extraction to match cashtags, rather than trying to extract the cashtag from the body itself. The description of how Twitter extracts entities can be found here: https://dev.twitter.com/overview/api/entities.
|
||||||||||||||||||||||||
bio: |
Matches a keyword or phrase within the user bio of a Tweet. This is a tokenized match within the contents of a user’s “bio” field.
|
||||||||||||||||||||||||
bio_name: |
Matches a keyword within the user bio name of a Tweet. This is a tokenized match within the contents of a user’s “Name” field.
|
||||||||||||||||||||||||
retweets_of: |
Matches tweets that are retweets of a specified user. Accepts both usernames and numeric Twitter Account IDs (NOT tweet status IDs).
|
||||||||||||||||||||||||
lang: |
Matches tweets that have been classified by Twitter as being of a particular language (if, and only if, the tweet has been classified). It is important to note that each activity is currently only classified as being of one language, so AND’ing together multiple languages will yield no results. Note: if no language classification can be made the provided result is ‘und’ (for undefined). The list below represents the current supported languages and their corresponding BCP 47 language indentifier:
|
||||||||||||||||||||||||
bio_location: |
Matches tweets where the user’s bio-level location contains the specified keyword or phrase. This operator performs a tokenized match, similar to the normal keyword rules on the message body. The user bio location is a non-normalized, user-generated, free-form string.
|
||||||||||||||||||||||||
time_zone: |
Matches tweets where the user-selected time zone specified in a user’s profile settings matches a given string. These values are normalized to the options specified on a user’s account settings page: [https://twitter.com/account/settings]
|
||||||||||||||||||||||||
statuses_count: |
Matches tweets where the author has posted a number of statuses that falls within the given range. If a single number is specified, any number equal to or higher will match. Additionally, a range can be specified to match any number in the given range.
|
||||||||||||||||||||||||
followers_count: |
Matches tweets where the author has a followers count within the given range. If a single number is specified, any number equal to or higher will match. Additionally, a range can be specified to match any number in the given range.
|
||||||||||||||||||||||||
friends_count: |
Matches tweets where the author has a friends count (the number of users they follow) that falls within the given range. If a single number is specified, any number equal to or higher will match. Additionally, a range can be specified to match any number in the given range.
|
||||||||||||||||||||||||
listed_count: |
Matches tweets where the author has been listed within Twitter a number of times falls within the given range. If a single number is specified, any number equal to or higher will match. Additionally, a range can be specified to match any number in the given range.
|
||||||||||||||||||||||||
is:verified |
Deliver only Tweets where the author is “verified” by Twitter. Can also be negated to exclude Tweets where the author is verified.
|
||||||||||||||||||||||||
source: |
Matches any tweet generated by the given source application. The value must be either the name of the application, or the application’s URL. Cannot be used alone.
|
||||||||||||||||||||||||
place: |
Matches tweets tagged with the specified location or Twitter place ID (see examples). Multi-word place names (“New York City”, “Palo Alto”) should be enclosed in quotes. Note: See the GET geo/search public API endpoint for how to obtain Twitter place IDs.
|
||||||||||||||||||||||||
place_country: |
Matches tweets where the country code associated with a tagged place/location matches the given ISO alpha-2 character code. Valid ISO codes can be found here: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
|
||||||||||||||||||||||||
has:geo |
Matches Tweets that have Tweet-specific geo location data provided from Twitter. This can be either “geo” lat-long coordinate, or a “location” in the form of a Twitter “Place”, with corresponding display name, geo polygon, and other fields. WARNING: Use this operator with care, it can generate large amounts of volume. Currently, this will deliver 1-4% of the firehose independently.
|
||||||||||||||||||||||||
has:mentions |
Matches Tweets that mention another Twitter user. WARNING: Use this operator with care. Used by itself, with no other limiting clauses, it can generate large amounts of volume. Currently, this will deliver double digit percentages of the firehose when used by itself.
|
||||||||||||||||||||||||
has:hashtags |
Matches Tweets that contain a hashtag. WARNING: Use this operator with care. Used by itself, with no other limiting clauses, it can generate large amounts of volume. Currently, this will deliver double digit percentages of the firehose when used by itself.
|
||||||||||||||||||||||||
has:images |
A boolean search operator that returns all tweets that contain a native images (e.g. pic.twitter.com). Please note that this a subset of has:media.
|
||||||||||||||||||||||||
has:videos |
A boolean search operator that returns all tweets that contain native videos (does not include vine, periscope). Please note that this a subset of has:media.
|
||||||||||||||||||||||||
has:media |
Matches Tweets that contain a media url classified by Twitter, e.g. pic.twitter.com. WARNING: Use this operator with care. Used by itself, with no other limiting clauses, it can generate large amounts of volume. Currently, this will deliver double digit percentages of the firehose when used by itself.
|
||||||||||||||||||||||||
has:symbols |
Matches Tweets that contain a cashtag symbol (with a leading ‘$’ character, e.g. $tag). Note: All ‘is:’ and ‘has:’ operators cannot be used as standalone operators and must be combined with another clause (e.g. @gnip has:links)
|
||||||||||||||||||||||||
is:retweet |
Deliver only explicit retweets that match a rule. Can also be negated to exclude retweets that match a rule from delivery and only original content is delivered. Note: This operator looks only for true Retweets, which use Twitter’s retweet functionality. Quoted Tweets and Modified Tweets which do not use Twitter’s retweet functionality will not be matched by this operator.
|
||||||||||||||||||||||||
is:quote |
A Boolean search operator that returns all quoted tweets. Deliver only explicit quote tweets that match a rule. Can also be negated to exclude quote tweets that match a rule from delivery. Note: This operator looks only for quote tweets, which use Twitter’s quote tweet functionality. ReTweets will not be matched by this operator.
|
||||||||||||||||||||||||
retweets_of_status_id: |
Deliver only explicit retweets of the specified Tweet. Note that the status ID used should be the ID of an original tweet and not a retweet. If extracting the ID of an original Tweet from within a Retweet for this purpose, look in the object.id field in Activity Streams format.
|
||||||||||||||||||||||||
in_reply_to_status_id: |
Deliver only explicit replies to the specified Tweet.
|
||||||||||||||||||||||||
has:profile_geo |
Matches tweets that have any Profile Geo metadata, regardless of the actual value.
|
||||||||||||||||||||||||
profile_point_radius:[long lat radius] |
Matches functionality described for the standard point_radius: operator, but only applies to geo-location data contained in the Profile Geo enrichment.
|
||||||||||||||||||||||||
profile_bounding_box:[west_long south_lat east_long north_lat] |
Matches functionality described for the standard bounding_box: operator, but only applies to geo-location data contained in the Profile Geo enrichment.
|
||||||||||||||||||||||||
profile_country: |
Exact match on the “countryCode” field from the “address” object in the Profile Geo enrichment. Uses a normalized set of two-letter country codes, based on ISO-3166-1-alpha-2 specification. This operator is provided in lieu of an operator for “country” field from the “address” object to be concise.
|
||||||||||||||||||||||||
profile_region: |
Matches on the “region” field from the “address” object in the Profile Geo enrichment. This is an exact full string match. It is not necessary to escape characters with a backslash. For example, if matching something with a slash, use “one/two”, not “one\/two”. Use double quotes to match substrings that contain whitespace or punctuation.
|
||||||||||||||||||||||||
profile_locality: |
Matches on the “locality” field from the “address” object in the Profile Geo enrichment. This is an exact full string match. It is not necessary to escape characters with a backslash. For example, if matching something with a slash, use “one/two”, not “one\/two”. Use double quotes to match substrings that contain whitespace or punctuation.
|
||||||||||||||||||||||||
profile_subregion: |
Matches on the “subRegion” field from the “address” object in the Profile Geo enrichment. In addition to targeting specific counties, these operators can be helpful to filter on a metro area without defining filters for every city and town within the region. This is an exact full string match. It is not necessary to escape characters with a backslash. For example, if matching something with a slash, use “one/two”, not “one\/two”. Use double quotes to match substrings that contain whitespace or punctuation.
|
Realtime/Historical PowerTrack-only Operators
Due to minimal usage combined with the cost to index in Search, the value and demand of support do not outweigh the cost. For this reason, it is unlikely we will ever offer support for these operators in our Search products.
| Operator: | Alternative: | Future State: |
|---|---|---|
| url_contains: | url: | url_contains was originally built as a substring match on the urls of a tweet. We have implemented a “url” operator that performs a tokenized match across all products. |
| contains | n/a | Contains is unlikely to be ever supported in search products as it is functionality that is nearly impossible/extremely expensive and not suited for how search technologies work. We may consider the potential of introducing support for Wildcards, as a replacement to contains, but there is no guarantee that will be supported in Search either. |
| source: | n/a | Operator has minimal usage that does not justify costly support in Search products |
| friends_count:, listed_count:, statuses_count: | n/a | Operator has minimal usage that does not justify costly support in Search products |
| retweets_of_status_id:, in_reply_to_status_id: | n/a | Operator has minimal usage that does not justify costly support in Search products |
Restrictions
- Stop words are not allowed as stand-alone terms in queries. If you need to find a phrase that contains a stop word, either pair it with an additional term, or use the exact match operators such as “on the roof”. As long as there is at least one required and allowed term in the rule, it will be allowed. Please note that this list of stop words is subject to change, but the current stop words we use are:
"a", "an", "and", "at", "but", "by", "com", "from", "http", "https", "if", "in", "is", "it", "its", "me", "my", "not", "or", "rt", "the", "this", "to", "too", "via", "we", "www", "you"
-
Rules cannot consist of only negated terms/operators. For example, ‘-cat -dog’ is not valid.
-
Powertrack rule format:
- Rules can be up to 2,048 characters long each, with no single term exceeding 128 characters
- No restrictions on the number of positive and negative clauses.
-
Negated ORs are not supported. Such as: apple OR -lang:en
-
Each rule may only have 1 tag. However, the tag is simply treated as a string, and may contain up to 255 characters, including - ; and other punctuation.
-
Geo rules with a radius greater than 25mi are not supported. Geo rules with a bounding box comprised of any edge greater than 25mi are not supported.
-
A rule keyword or input can start with either a digit (0-9) or any non-punctuation character. Current punctuation characters are defined as the ASCII characters below. Any keyword or input that needs to start with or contains punctuation must be “quoted”. A keyword can not have a colon or parentheses unless you quote it. Punctuation characters are not indexed and thus cannot be matched on, even if using the exact match operator.
! % & \ ' ( ) * + - . / ; < = > ? \\ , : # @ \t \r \n " [] _ and the Unicode ranges: U+007B -- U+00BF U+02B0 -- U+037F U+2000 -- U+2BFF U+FF00 -- U+FF03 U+FF05 -- U+FF0F
- PowerTrack rules do not allow zero-width characters that exist in the General Punctuation block:
http://www.fileformat.info/info/unicode/block/general_punctuation/list.htm
Note that any characters in the above link that don’t have a visible symbol associated with them. The characters mentioned below change how text is formatted on the screen but not it’s intended meaning (for directional markers in particular, different keyboards will put different combinations of these characters in identical-looking text), and as such are not considered during text parsing.
PowerTrack rules allow-but-ignore the following characters list:
'U+202A', 'U+202B', // explicit directional embeddings 'U+202D', 'U+202E', // explicit directional overrides 'U+202C', // pop directional formatting 'U+2066', 'U+2067', 'U+2068', // explicit directional overrides 'U+2069', // pop directional isolate 'U+200E', 'U+200F', 'U+061C' // implicit directional marks / arabic letter mark