Keyword matching rules

A condition node compares the text of the message that reached it against the words configured on that node, then sends the execution out of Match (output 0) or No Match (output 1). With the Keyword list match type, a message matches when it contains at least one keyword from the list. Reverse matching inverts that result, and a list with no keywords — or one that has been deleted — matches every message.

Summary

Match type	Settings it reads	A message matches when
any	none	Always. The node keeps one output and every message follows it
contains	text	The message contains the configured text
exact	text	The message is the configured text and nothing else
keyword_list	keyword_list_id, reverse_keywords	The message contains at least one keyword from the list, or none of them when reverse matching is on

The matching algorithm

1. The condition takes the text of the message that started the execution — the comment, or the direct message.
2. A condition set to wait for a reply parks the execution instead of comparing anything, and compares the text of the reply when it arrives. A pressed button counts as text: the button’s label is what the condition compares.
3. The match type decides the comparison. keyword_list loads the saved list by its identifier and tests the message against that list’s keywords.
4. Reverse matching inverts the result of a keyword_list comparison, so a message containing none of the keywords matches.
5. A keyword list with no keywords in it, and a reference to a list that no longer exists, both produce a match without comparing anything.
6. The result picks the output. Match is output 0, No Match is output 1, and the execution continues along whichever one carries a connection. An output with no connection ends the execution at the condition.
7. Media filters on the same node — images, GIFs, and links — are separate settings and take no part in the keyword comparison, though a message that fails one still leaves by No Match.

Keyword settings live on the condition node. A trigger node decides which events start a campaign and holds no keyword configuration at all, so a campaign filters text only once its execution reaches a condition. Node types lists the configuration of both.

any

• Reads: nothing
• Outputs: 1

Every message matches, with no comparison performed. Switching a condition to any drops the node’s second output and removes any connection leaving it, so the No Match branch cannot exist while this match type is selected.

contains

• Reads: text
• Outputs: 2

The message matches when the configured text appears inside it. text holds one string rather than a set of alternatives — use a keyword list when you need several.

exact

• Reads: text
• Outputs: 2

The message matches when it is the configured text and nothing else.

keyword_list

• Reads: keyword_list_id, reverse_keywords
• Outputs: 2

The message is compared against a saved keyword list, chosen from the node’s dropdown, and matches when it contains at least one of that list’s keywords. The list is read by its identifier at match time, so editing the list changes what this node matches without re-saving the campaign. Match comments with keyword lists covers creating a list and attaching it.

{
  "type": "condition",
  "config": {
    "match_type": "keyword_list",
    "keyword_list_id": 41,
    "reverse_keywords": false,
    "wait_for_reply": false,
    "filter_images": false,
    "filter_gifs": false,
    "filter_links": false
  }
}

Keywords are cleaned when the list is saved, not when a message arrives: leading and trailing spaces are trimmed, blank entries are dropped, and repeated entries collapse to one. A list submitted with no keywords is refused.

One list can back any number of condition nodes, across campaigns and pages, because the node stores the list’s identifier rather than a copy of its words.

Reverse matching

reverse_keywords applies to the keyword_list match type and inverts the outcome of the comparison. Match then carries the messages that contain none of the keywords, and No Match carries the ones that contain at least one. Nothing else about the comparison changes.

An empty or deleted keyword list

Situation	What the condition does
The list has no keywords in it	Matches every message
The list the node points at has been deleted	Matches every message

A condition that suddenly responds to everything usually has one of those two causes. A condition node’s reference to a list lives inside the campaign’s saved graph, which is why a list can disappear from under a node that still points at it — Match comments with keyword lists covers what deletion does and does not refuse.

Worked examples

Comment text	Condition setting	Reverse matching	Branch taken
How much is shipping?	Keyword list holding shipping and price	off	Match
How much is shipping?	Keyword list holding shipping and price	on	No Match
Beautiful, congratulations	Keyword list holding shipping and price	off	No Match
Beautiful, congratulations	Keyword list holding shipping and price	on	Match
Beautiful, congratulations	Keyword list with no keywords in it	off	Match
Beautiful, congratulations	Keyword list that has been deleted	off	Match
A sticker with no text, which arrives as {{sticker}}	Keyword list holding shipping and price	off	No Match
A sticker with no text, which arrives as {{sticker}}	Keyword list holding {{sticker}}	off	Match
How much is shipping?	contains, with text set to shipping	not applicable	Match
Anything at all	any	not applicable	Match, on the node’s single output

Case, whole words, punctuation, and emoji

A message matches by containing a keyword, but how the two strings are prepared before that test is not confirmed. Treat each statement below as the expected behaviour rather than a guarantee, and test the ones your campaign depends on:

• Letter case is ignored, so a comment reading Shipping matches a keyword of shipping.
• A keyword matches inside a longer word, so ship matches a comment reading shipping.
• Punctuation beside a keyword does not prevent a match, so shipping? matches a keyword of shipping.
• Emoji are compared as ordinary characters, so a keyword holding one emoji matches a comment containing that emoji.

What a keyword list stores is settled, whatever the comparison turns out to do: spaces around an entry are trimmed on save, so a keyword can never carry leading or trailing whitespace into a comparison.

Until the rest is confirmed, settle each keyword with a test execution from the canvas: run the campaign against the exact text you expect to receive and read which output the condition took. See Test and debug a campaign.

Notes

• A comment carrying no text arrives with a placeholder in place of the message — {{sticker}} on Facebook, {{media}} on an Instagram reply — so a condition always has something to compare. A keyword list holding that exact string matches those comments.
• An execution parked at a condition waiting for a reply keeps the keyword set it started with. A reply arriving after you edit the list is matched against the old keywords; the next execution uses the new ones.
• A condition with the image filter turned on does not match a reply that carries no image, and routes it to No Match whatever the keywords say.
• Changing a condition’s match type or text on the canvas alters the campaign in your browser only. A live execution compares against the saved version of the graph it started on, so the change applies to new executions once you save.
• A condition never connects to another condition, so a branch tests message text once. Two tests on one path need two branches, or a keyword list that covers both sets of words.

Related

• Match comments with keyword lists — creating a list, attaching it to a node, and what happens when you edit or delete one.
• Node types — the condition node’s full configuration, alongside every other node.
• Campaign graph schema — where a condition’s configuration sits in a saved graph.
• Trigger events — the events that produce the text a condition compares.
• Contact fields — what an execution can change about a contact after it leaves the Match output.