What is an Unknown?
An unknown registrant is created when the Authorizer widget loads and does not have enough information for the registrant to create the registrant with a name, email etc.
Why does this happen?
The Authorizer widget can pick up whatever has been entered in or stored for a registrant that registers socially or manually but only if in the Auto-Filler widget has loaded before the Authorizer in the same path for that specific user. and only if the Auto-filler has fields properly defined that can both set and obtain the data from the `form` fields on that previous page.
There are several problems with these conditions:
1) we can't guarantee that this path will always include the Auto-Filler in such a way. Installers have told us quite a number of times that "this is the only path," and only after some research later in event review or when the customer complains later do we find out that there are more than the disclosed paths to the page that the Authorizer widget loads on.
2) There are cases where CORS security restricts our ability to create the hidden iFrame or cookie values used in this "inter-page-data-storage" mechanism that we are using as described above. In those cases, the iFrame will fail to record the data required for the Authorizer widget.
3) It is important to note also that when a user authorizes socially, this mapping is never required. When the user has authorized socially, their data from the social network is stored for their registration "session". It is important to note too, however, that the Auto-filler's role is to also pick up changes the user makes to this data through their registration path (e.g. Facebook has a first name of "Joey" which the Auto-filler automatically enters into the designated form field when activated. But the user changes "Joey" to "Joe" when filling out the form. The Auto-Filler would pick this up and apply this to that registrant's data. When the Auto-Filler is not used in the registrant's path, social registrants will be recorded exactly as given to us by the Social Network, which could cause slight discrepancies with the recorded registrant data that a customer has and the data that we have for the registrant (E.g. we have "Joey" and the customer has "Joe").
InGo ProTip: Always Map the Authorizer Widget!
Given those restrictions/considerations, it's best if the installer always maps or configurs the Authorizer widget. See the article on mapping the Authorizer widget for more details.
Also note, that it is possible to map the Authorizer widget using the LONG form of the widget loading. This loading sequence allows a customer to run whatever script they need to outside of and before the widget loads. So, for example, if the registrant's information is present on the page, they can "pick it up" and then call the Authorizer widget with that data, thereby ensuring that the Authorizer is mapped.
Now go and unknown no more!