I have a question about connection between mturk and qualtrics. I published a survey on mturk. However, when I browse the results on qualtrics, I can't match mturk id with the qualtrics id. I also can't match them with the timestamps either since they provide different timestamps (I'm not sure why). Is there any way that i can match the two ids after I got results? Many thanks!
Usually within the Qualtrics survey you give the worker a code to enter back into the Mturk hit. Or alternatively, you can ask the worker to submit their worker id into your qualtrics survey.
There are numerous guides online as to how to do this. I have linked one.
http://www.tylerjohnburleigh.com/mturk/2013/05/mturk-confirmation-code-with-qualtrics/
The Qualtrics ID is an Id identifying a respondent on qualtrics and will be determined randomly no matter where the respondent came from. To link Qualtrics with MTurk you could for example explicitly ask for the MTurk ID in your survey. Using the piping tools you could even connect this entry with the passcode you give out to participants at the end of the survey (see the answer given by Burnt), which is then again entered into the MTurk HIT.
Related
[Problem]
I'm currently having a problem where the same conversation/thread gets allocated to multiple labels/folders. And I want to have a setup where:
If a specific person sends an email or sends an email with a specific subject, it'll go to a specific label.
If someone replies to that conversation, it'll stay in that label that it originally arrived in and it won't appear in any other label. And it wouldn't go to the inbox as well.
[Setup]
I believe my current setup causes the above problem to happen because I have countless filters that uses the same person for From and/or To. So to prevent it as much as possible, I try to use the subject field, to which it works. However, I'm still getting conversations with multiple labels that are not related to any other subjects, so it's very difficult to manage.
[Question]
Is there a way where I could always keep the conversation in the label where it first arrived no matter who or how many people replies to that specific conversation? Should I use apps script? Is there any kind of best practices that you recommend?
I am trying to make a search algorithm with dialogflow that could take any combination of: first name, address, phone number, zip code or city as input to a search algorithm. The user does not need all of them, but we will refine our search with each additional answer until we only have one result. Basically we are trying to identify which customer we are talking to.
How should this type of intent (or set of intents) be structured? We have tried one intent with multiple parameters, but we do not need all of them to be required. We have also written a JavaScript function for fulfillment but how can we communicate back to dialogflow as to whether we need more information?
Thank you very much for your help.
Slot filling is designed for this purpose.
Hope that helps.
Please post more code/details to help answers be more specific.
First, keep in mind that Intents reflect what the user is saying, and not typically what you're replying with or what other information you need. Slot filling sometimes bends this rule, but only if you have required slots.
Since you don't - you need a different approach.
This can be done with a single intent, although you may find that multiple intents make it easier in some ways. The approach is broadly the same:
When you ask the question, make sure you set an Outgoing Context with a relatively short lifespan (2-3 is good) to indicate you are collecting user info.
Create an Intent (or Intents) that have sample phrases that capture the information you need.
Some of these will have obvious entity types (phone number and zip code) while others will be more difficult (First name has a system entity type, but it doesn't include all possible first names).
You will need to create sample phrases that collect the parameters by themselves, along with phrases that make sense. You're the best judge of this, and you should probably write some sample conversations before you write the phrases.
In your fulfillment, you'll figure out if you have enough information.
If you do, you can reply and clear the Context that was set. (Clearing it is important so Dialogflow doesn't match the information collecting Intent again.)
If you do not, you can add the information you have as parameters to the Context so you can save it for later processing, make sure you reset the Context lifespan (so it doesn't expire), and prompt the user for additional information. Again, having a conversation mocked out ahead of time will help here.
I am trying out some things with Google Dialogflow. The thing I am basically trying to do is ask the user's age. Based on the age, say greater than 50 OR smaller than 50, I want the user to be guided to a specific question for one of the two age groups.
I was looking on the internet for a hint or suggestion, but I can't find examples other than "Yes","No" type of answers which then guide the user to a specific flow.
I basically need the user to say an age, which can be between 1-50 years, and 50-100 years, and any number belonging to any of the two groups should prompt the user to a specific follow-up question for that age group.
Does any one have a tip? Is this even possible in the generic Google Dialogflow? Or would I need to use a webhook/fullfilment for this?
Thanks and regards
The easiest way is to use fulfillment for this sort of thing. Dialogflow Intents are good at capturing what the user has said, and possibly including this as a parameter, but webhooks are best for applying logic and determining output and what context further answers should be considered in.
What is a best way to parse an email with bug description. One client decided recently that it would be nice for user to be able to send an email to known mailbox and a bug would be registered in bug tracker (not exactly bu close).
The problem is bug description has lot of fields like dates, times, descriptions, comments, losses, attachments etc. Relying on user to use some specific mail format is not the smartest thing to do.
The question is how could one parse email to get all needed information. The format should be not to strict, but enough to guess what fields mean what. I would also be interested to hear both correct and easiest solutions for this.
P.S.
Actually this feature was requested by a bank. They have a public mailbox where clients would sends discovered issues. The problem is to get as much information from these letters before bank employee will actually look at it.
We do something similar to this with RT, however the email isn't really parsed. All the emails go into a single queue where it is evaluated by our IT staff. Basically, the parsing is done by humans - they modify the ticket to have as much information as they can glean from the email.
You're unlikely to get users to adhere (correctly) to any special syntax or formatting you come up with - unless they are employees, highly trained, or have some incentive to follow your rules.
Another option would be to have the initial email respond with an email that is formatted as a questionaire. In other words, the user writes an initial bug report and immediately (or as soon as your email server can respond) gets back a "thank you - can you provide more info" message with prompts for more info. You could then parse that email and have it populate your bug tracking system with more accurate info,
Good luck! Sounds like a cool idea!
FogBugz has the ability to monitor an email address and add emails sent to that address as a new FogBugz cases.
There's also a feature called ScoutSubmit that accepts HTTP GET arguments and uses those to submit a new case. Very handy for having a application automatically submit bug reports from the field.
Categorizing a bug based on freeform text is a difficult proposition. Very little besides the defect submitter name and the date the bug is reported is easily gleened from an email. Is there a reason you are limiting yourself to email? If you provide a form to submit the bugs via a webpage you can categorize the defect/bug based on dropdown menu items you present to the user. In addition you can point them to common answers in a dynamic information portion of the page. Have a look at Apple iTunes support request page for a slightly annoying but effective method to force the user to give you decent information. Banking applications are not a good domain to allow ambiguity nor are they a good domain to have multiple rounds of communication.
I've wondered about this for some time now. I'm wondering webforums implement the option to highlight something you haven't read. How the forum knows.
Since most webforums have a function to show you all posts since your last visit, they must save the last time you visited one of their pages in your userdata in the database.
But that doesn't explain how individual topics are still highlighted after you've read just one.
A many to many table connecting a user to a topic/post with flags for read/favorite etc.
Many web forums store a huge list of the last time you looked at each topic you've looked at.
This gets out of hand quickly, but there are mitigations. See Determining unread items in a forum
Keeping track of what posts a visitor has read is of course not that much of a big deal. Since it's highly likely that the number of posts a visitor read will be much less than the posts not read. So, if you know what posts a visitor has read, you also know what posts this visitor didn't read. To make this less computational intensive you'd normally do this only over a certain period of time, say the last two weeks. Everything before that time will be considered read.
Usually, this list of "unread" items only shows changes that have been made since the last time you logged out.
Use the user's last activity date/time to mark items as "unread" (any activity in a topic after that time is marked "unread"). Then store in a Session variable, a list of topic IDs that the user viewed since last login. Combining these two would give you a relatively accurate list of unread topics.
Of course this data would then be lost on log-out or session expire and the cycle would start again without sacrificing an unnecessary amount of SQL queries.
On the custom forum I used to work with, we used a combination of your last visit time (updated every time you viewed another page - usually cookied), and a "mark read" button on each topic that added a date/time value to a SQL table containing your UserID, the TopicID and the Date/Time.
Thus to view new topics we would look at your last visit date and anything created after that point in time was a new topic.
Once you entered a topic any topic you had clicked "mark read" on would only show the initial topic and then any replies with a date/time added after you clicked the mark read button. If you have fewer viewers and performance to spare you could basically set it up to add an entry to the table for every topic the user clicks on, when they click on it.
Another option you have, and I have actually seen this done before in a vBulletin installation, is to store a comma separated list of viewed topic ids client-side in a cookie.
Server-side, the only thing stored was the time of the user's previous visit. The forum system used this in conjunction with the information in the user's cookie to show 'as read' for any topic where either
Last modified date (ie last post) older than the user's previous visit
Topic ID found in the user's cookie as a topic the user has visited this session.
I'm not saying it's a good idea, but I thought I'd mention it as an alternative - the obvious way to do it has already been stated in other answers, ie store it server-side as a relation table (many to many table).
I guess it does have the advantage of putting less burden on the server of keeping that information.
The downsides are that it ties it to the session, so once a new session is started everything that occurred before the last session is considered 'already read'. Another downside is that a cookie can only hold so much information, and a user may view hundreds of topics in a session, so it approaches the storage limit of the cookie.
One more approach:
Make sure your stylesheet shows a clear difference between visited and non-visited links, taking advantage of the fact that browsers remember visited pages persistently.
For this to work, however, you'd need to have consistent URLs for topics, and most forum systems don't tend to do this. Another downside to this is that users may clear their history, or use more than one browser. This therefore puts this measure into the 'not highly reliable category'; you would probably just do this to augment whatever other measure you are using to track viewed topics.