Последние сообщения

Я просто знаю примерный бюджет который они закладывают, было бы полезно понимать как они его тратят. Читал где то, что по utm можно определить, а как до дела дошло, смотрю везде cpc, че то думаю не то.

Летом будет я подозреваю по более бюджет. Его появление неизбежно? Как бы учитывая что я манипулировать директом пытаюсь, мне эти менеджеры лишний раз как бы не особо то и нужны.

Жаль. Может как то тенденцию можно отследить?

Егор Савельев

Какой у вас бюджет в месяц?

Примерно от 100 в месяц появляется менеджер по Директу и у него можно запросить отчёт по конкурентам от 4 шт. — обезличенный

А Вам зачем? Вы их результат вряд ли повторите, даже используя ту же стратегию. Их там на выбор то всего 3 по сути. Проще эксперимент у себя настроить на все 3.

Жаль. Может как то тенденцию можно отследить?

Нельзя. Стратегия с метками никак не связана, если реклама намеренно не внес такую метку. И то, отметить он это может как 1, 2, 3..

Все хорошо, но нужны ссылки. Первое, ссылки с жирных сайтов и из США, Китая.

Второе, просто перевести с помощью ИИ на английский недостаточно, у Вас будет ломанный английский. Нужно самому переводу текста делать опять перевод на русский (обратный перевод), чтоб понять в каком плане нужно изменить. Английский язык не всегда понимает русские словосочетания, наречия и т.п. Для англосаксов понятие «Старый новый год» взрывает мозг. У них речи, принеси, подай и иди на х… не мешай.

Третий момент. Если Вы всё четко сделали, то стоит подождать минимум 3-и месяца, чтоб обновилась инфо. Гугл в последнее время вообще ленивым стал, поэтому может и больше.

Четвертый момент. Нужно исправлять все ошибки в Серче консоле. Чтоб страниц неиндексируемых было в разы меньше индексируемых. Иногда Гугл нужно просто делать переобходом косячных страниц, а иногда и исправлять ошибки. Например, в микроразметке Гугл не воспринимает кавычки, не указано верно время (международный формат) и т.п. Помогают сервисы быстрой индексации страниц. На каждую страницу на Вашем сайте должны идти внешние ссылки.

Пятый момент. Валидатор не является этапом ранжирования сайта. Да, круто когда нет ошибок, может на 0,1 секунды загрузится быстрее, но при этом столько геморроя. Проверено, если Вам нужно что-то разместить важное, а валидатор выдает ошибки, забейте на этот валидатор болт.

Ну и последний, шестой момент. Вообще интернет начал развиваться благодаря тому, что крупные издатели New York Times, Washington Post не могли оптимизировать свои статьи так, чтоб их читали пользователи. Появился поиск. Исходя из этого, Вы скажите этим изданиям оптимизировать свои статьи под Гугл, Вас засмеют, так как они и есть этот поиск. Другими словами, нужно знать основы SEO, но прям писать SEO тексты — это утопия.

Егор Савельев, ссылки покупал, но качество проверить не могу. достаточно часто обновлял, пока не забил из-за отсутствия трафика.

Тематика? Ссылки покупаете? Как часто обновляется контент? Текста сами пишите или переводом через deepl?

Сайт под США очень тяжело поднять, все известные вам способы в ру сегменте не помогут от слова совсем.

Удалять

active

id

CREATE TABLE entity (     id INT(11),     name VARCHAR(50)     ); CREATE TABLE active_entity (     active_id INT(11)     ) SELECT 0 active_id;  CREATE TRIGGER store_active AFTER INSERT ON entity FOR EACH ROW UPDATE active_entity SET active_entity.active_id = CASE @active                                WHEN TRUE                                THEN NEW.id                                ELSE active_entity.active_id                                END; 

Следующее предложение может работать здесь как альтернатива вашему нынешнему подходу. Вместо текущего дизайна таблицы используйте этот:

CREATE TABLE entity (     id INT NOT NULL AUTO_INCREMENT,     name VARCHAR(50),     -- other columns here ); 

Предполагая, что последовательность автоматического увеличения всегда увеличивается, вы можете просто найти запись активного имени, используя:

SELECT * FROM entity WHERE name = 'blah' ORDER BY id DESC LIMIT 1; 

В случае, если две вставки с одинаковым именем поступают почти одновременно, MySQL всегда гарантирует, что одной из них будет присвоен самый высокий (последний)

id

entity

А смысл писать, если там этот компонент выйдет в новой версии, тем более логично что там пишет команда, а тут Вы один будете, проще дождаться уже. 

Вот общий план, как можно реализовать компонент бронирования в ДСТ Мед:

Backend1. Модель бронирования:

class Booking extends Model {
protected $fillable = ['doctor_id', 'user_id', 'status', 'appointment_time'];
 
public function doctor() {
return $this->belongsTo(Doctor::class);
}
 
public function user() {
return $this->belongsTo(User::class);
}
}

1. Контроллер бронирования:

class BookingController extends Controller {
public function create(Request $request) {
$booking = Booking::create([
'doctor_id' => $request->doctor_id,
'user_id' => $request->user_id,
'status' => 'pending',
'appointment_time' => $request->appointment_time,
]);
 
return response()->json($booking);
}
 
public function updateStatus(Request $request, $id) {
$booking = Booking::find($id);
$booking->status = $request->status;
$booking->save();
 
return response()->json($booking);
}
 
public function index() {
$bookings = Booking::with('doctor', 'user')->get();
return response()->json($bookings);
}
}

1. Маршруты:

Route::post('/bookings', [BookingController::class, 'create']);
Route::put('/bookings/{id}/status', [BookingController::class, 'updateStatus']);
Route::get('/bookings', [BookingController::class, 'index']);

Frontend1. Форма бронирования:

<form id="bookingForm">
<input type="hidden" name="doctor_id" value="{{ doctor.id }}">
<input type="hidden" name="user_id" value="{{ user.id }}">
<input type="datetime-local" name="appointment_time" required>
<button type="submit">Забронировать</button>
</form>

<script>
document.getElementById('bookingForm').addEventListener('submit', function(e) {
e.preventDefault();
const formData = new FormData(this);
 
fetch('/bookings', {
method: 'POST',
body: formData
}).then(response => response.json())
.then(data => {
alert('Бронирование успешно создано!');
});
});
</script>

1. Админка для управления бронированиями:

<table id="bookingsTable">
<thead>
<tr>
<th>Врач</th>
<th>Пациент</th>
<th>Время</th>
<th>Статус</th>
<th>Действия</th>
</tr>
</thead>
<tbody>
<!-- Здесь будут строки с бронированиями -->
</tbody>
</table>

<script>
function loadBookings() {
fetch('/bookings')
.then(response => response.json())
.then(data => {
const tableBody = document.querySelector('#bookingsTable tbody');
tableBody.innerHTML = '';
data.forEach(booking => {
const row = document.createElement('tr');
row.innerHTML = `
<td>${booking.doctor.name}</td>
<td>${booking.user.name}</td>
<td>${booking.appointment_time}</td>
<td>${booking.status}</td>
<td>
<select onchange="updateStatus(${booking.id}, this.value)">
<option value="pending" ${booking.status === 'pending' ? 'selected' : ''}>В ожидании</option>
<option value="accepted" ${booking.status === 'accepted' ? 'selected' : ''}>Принято</option>
<option value="rejected" ${booking.status === 'rejected' ? 'selected' : ''}>Отказано</option>
</select>
</td>
`;
tableBody.appendChild(row);
});
});
}
 
function updateStatus(id, status) {
fetch(`/bookings/${id}/status`, {
method: 'PUT',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ status })
}).then(response => response.json())
.then(data => {
alert('Статус обновлен!');
loadBookings();
});
}
 
loadBookings();
</script>

База данных1. Миграция для таблицы бронирований:

Schema::create('bookings', function (Blueprint $table) {
$table->id();
$table->foreignId('doctor_id')->constrained();
$table->foreignId('user_id')->constrained();
$table->string('status');
$table->timestamp('appointment_time');
$table->timestamps();
});

Этот пример демонстрирует базовую реализацию компонента бронирования. Вы можете адаптировать его под вашу конкретную архитектуру и требования.

Использовать:

SELECT t.contactid     FROM YOUR_TABLE t    WHERE flag IN ('Volunteer', 'Uploaded') GROUP BY t.contactid   HAVING COUNT(DISTINCT t.flag) = 2 

Главное, чтобы подсчет

t.flag

IN

Использование

COUNT(DISTINCT t.flag)

SELECT t.contactid     FROM YOUR_TABLE t    WHERE flag IN ('Volunteer', 'Uploaded') GROUP BY t.contactid   HAVING COUNT(t.flag) = 2 

Вы можете использовать

GROUP BY

HAVING COUNT(*) = _

SELECT contact_id FROM your_table WHERE flag IN ('Volunteer', 'Uploaded', ...) GROUP BY contact_id HAVING COUNT(*) = 2 -- // must match number in the WHERE flag IN (...) list 

(при условии

contact_id, flag

Или используйте объединения:

SELECT T1.contact_id FROM your_table T1 JOIN your_table T2 ON T1.contact_id = T2.contact_id AND T2.flag = 'Uploaded' -- // more joins if necessary WHERE T1.flag = 'Volunteer' 

Если список флагов очень длинный и много совпадений, первый, вероятно, будет быстрее. Если список флагов короткий и совпадений мало, вы, вероятно, обнаружите, что второй быстрее. Если производительность вызывает беспокойство, попробуйте протестировать оба варианта на своих данных, чтобы определить, какой из них работает лучше всего.