I'm seeing this as well on my end using Find 13.01. I've seen this before and in the past it was generally do to issues with sending incorrect data due to tracking manually. I'm not sure this is the case right now since I believe this worked on an earlier version.

The user/application flow is as follows:

1. User searches for "food"
2. Our find implementation does a multisearch and performs manual tracking using client.Statistics().TrackQuery(..)
3. User clicks on item in search results
4. We perform another manual click tracking client.Statistics().TrackHit(...) using the hitid of = "OurNamespace_ClassName/_c51467bc-e0a3-461a-b1da-3be201cb9971_en"

On the admin side:

1. The admin logs in and goes to /EPiServer/Find/#manage
2. Sees "food" with 1 query
3. Clicks on "food" to bring up the details and sees "1 Page not found." with 1 click.

Behind the scenes Fiddler shows a request made to /my_private_find_api/my_find_index/_mget?fields=SearchTitle$$string with the body of 

{"docs":[{"_type":"OurNamespace_ClassName","_id":"_c51467bc-e0a3-461a-b1da-3be201cb9971_en"}]}

Response:

{"docs":[{"_index":"my_find_index","_type":"OurNamespace_ClassName","_id":"_c51467bc-e0a3-461a-b1da-3be201cb9971_en","exists":false}]}

It seems as if this should be working correctly. I am indexing both the hittype and hitid and they match as the data as well.

Any thoughts?

Okay so this is what I found out. 


I have a custom class that I index called SearchEntity. I use this for pages, persons, documents. So basically in my index I have one type of indexed object called SearchEntity.


My fault was that When tracking a hit, I send; 

OurNamespace_StandardPage OR OurNamespace_Person followed by "/" and the Id ("_a33544c-g545g-a4bb5-e4as-3b4eabb345_sv"). 

When I should have sent;

OurNamespace_SearchEntity/_a33544c-g545g-a4bb5-e4as-3b4eabb345_sv.

You need to make sure that the HitType you send corresponds to the $type your indexed item has. 

also

I think the Property decorated with the [Id]-attribute for the indexed item must match the HitId you send.

Finally. Make sure your class has the property SearchTitle implemented, since this will be what is displayed instead of "Page not found" (I atleast think this is the case. Read it in a similar thread)

And in Fiddler the only response to find-api is with a ok-response so I have no clue where the fault is. It's difficult to troubleshoot since this happens when I use UnifiedSearch as well as manually creating the tracking url so no luck finding differences there.

Okay so you have SearchTitle in the indexed object. 

Do you index custom classes or is it regular content? 

How do you generate the hitId and the hitType?

Otherwise you could contact EPiServer support and ask if there's anything wrong with the index.

Are you sure HitType == $type? I believe "." is replaced with "_". Our.Namespace.BlogPostPage => Our_Namespace_BlogPostPage for HitType. I have confirmed this is the case for our new implementation and existing (working) implementations.

HitId appears to be "_{ContentGuid}_{two letter language code}"

SearchTitle is populated in the index.

No i meant that the HitType needs to match the type. Not that  it needs to be a string match. 

If type is namespace.article the HitType would be something like namespace_article

HitId also needs to match the id in the index.

if the indexed object id is _guid_guid_sv then the hitId needs to be the same and if the indexed id is 1234_abcd the hitId  should be the same. 

Is that something I can check in the Find/Overview/Explore page or any I don't see anything with that property name Id, or any properties with the value of my hitid ("_c51467bc-e0a3-461a-b1da-3be201cb9971_en".)

I'm going to guess we cannot as I just checked a working index/site and do not see that property or hitid value.

I think you missunderstand me. I was merely giving insights on how I solved my own problem. 

You probably work with regular content while I do Not. In the solution I work with, we index our own customclass for whatever content we want to Index. . 

So when you track your clicks you would send;

OurNamespace_SomeContentType/_c51467bc-e0a3-461a-b1da-3be201cb9971_en
while I would send something like;
OurNamespace_SearchEntity/c51467bc-e0a3-461a-b1da-3be201cb9971

So this is part of the object I use for indexing. 
public class SearchEntity 
{
[Id]
public string Id { get; set; } <- This is the ID for my indexedobject and it will be whatever I chose to put there. Either a random Guid or the actual id of the IContent I index.
public string ExternalId { get; set; }
public string Title { get; set; }
public string Url { get; set; }

So what I meant was; 
I need to send in the actual ID of the indexed object and the actual TYPE of the indexedobject whenever I track a click otherwise it won't be found. 

When I got Page not found in the trackclick view I was sending;
OurNamespace_SomeContentType/_c51467bc-e0a3-461a-b1da-3be201cb9971_en

(Cause the content connected to the SearchEntity had that type and that Id). And ofcourse it did't find it. There was nothing in the index with that ID or that type. 

Thanks for the reply. Unfortunately, I am indexing/searching for non custom classes and the values match in the index. I might try to create a small site for testing to see if there is a bug somewhere.

Hi

I am having the same issue, in my situation I also need to implement custom tracking.

After the search I manually track the query using

string trackingId = new TrackContext().Id;

SearchClient.Instance.Statistics().TrackQuery(model.Query, x =>
{
x.Id = trackingId;
x.Tags = ServiceLocator.Current.GetInstance<IStatisticTagsHelper>().GetTags(false);
x.Query.Hits = model.NumberOfHits;
});

Then iterate each of the results and associate a hit ID using the following extension method

public static string HitTrackingId(this PageData pageData)
{
if (pageData == null)
{
return null;
}

string hitId = SearchClient.Instance.Conventions.IdConvention.GetId(pageData);
string hitType = SearchClient.Instance.Conventions.TypeNameConvention.GetTypeName(pageData.GetType());
string hitTrackId = $"{hitType}/{hitId}";

return hitTrackId;
}

Which gives us the correct format "Namespace_Pages_MyPage/_ba434590-fd1a-4d8b-a99b-d821b9e5bb8f_en-NZ"

Once a user selects a search result we pass the trackingId, query and hitId using

SearchClient.Instance.Statistics().TrackHit(trackHit.Query, trackHit.HitId, command =>
{
command.Hit.Id = trackHit.HitId;
command.Id = trackHit.TrackId;
command.Ip = "127.0.0.1";
command.Tags = ServiceLocator.Current.GetInstance<IStatisticTagsHelper>().GetTags(false);
command.Hit.Position = null;
});

I can see in Fiddler the request go through "https://es-ap-api01.episerver.net/someid/someindex/_track?id=1B2M2Y8AsgTpgAmY7PhCfg==&ip=127.0.0.1&q=query&hit.id=Namespace_Pages MyPage/_687eda39-7eb8-4ec2-b1ed-40816faa886a_en-NZ&tags=andquerymatch,language:en,siteid:..."

We have also added a SearchTitle property to the PageType

/// <summary>
/// Required for search tracking
/// </summary>
public string SearchTitle
{
get { return Heading; }
}

When I look within Find the hits are registered but they all say Page Not Found and I can't see any of the hits boosting as we require when using .UsingAutoBoost(TimeSpan.FromDays(14));

If I look in the index the hitID and type match OK

Any ideas what I'm missing?

This is a confirmed bug (FIND-3091) fixed in upcoming Find 13.1.0

Great, thanks for the update!